SSD Nodes Learn 🎉 VPS من $4.99/شهر
الأدلة Matt Connorبقلم Matt Connor

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

تعرّف على ما تتحمله مستويات RAID 1 و5 و6 و10، وتكلفة إعادة البناء، ولماذا يختار مستضيفو VPS RAID 10 لـNVMe، مع قراءة /proc/mdstat ولماذا لا يُعد RAID نسخة احتياطية.

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

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

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

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

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

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

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

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

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

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

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

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

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

ChartEight 1 TB drives: usable capacity and drives lost before data loss
The data behind this chart
[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "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. هذا الفرق يعني تكلفة فعلية، ولهذا يستمر اقتراح استخدام التكافؤ. يتحمل RAID 6 2 أعطال، مهما كان نمطها. أما RAID 10 فيضمن فقط 1، لأن العطل الثاني الخطير هو الذي يصيب شريك المحرك الذي تعطل بالفعل. ويمكنه تحمل ما يصل إلى 4 أعطال عندما لا يشترك أي عطلين في زوج واحد، لكن ذلك يعتمد على الحظ وليس على خاصية تصميمية.

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

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

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

ChartDevice operations per small random write, and drives read during a rebuild
The data behind this chart
[
  {
    "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)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

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

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

لماذا تشكّل إعادة البناء الجزء الأخطر

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

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

توجد أيضاً مخاطرة تتعلق بسلامة البيانات خلال الفترة نفسها. تفقد مصفوفة RAID 5 التي تحتوي على محرك أقراص متعطل أي تكرار للبيانات، ولذلك يصبح أي قطاع يتعذر قراءته على محرك أقراص سليم غير قابل للاسترداد. إعادة البناء هي العملية الوحيدة التي تقرأ كل قطاع، بما في ذلك القطاعات التي لم يلمسها أحد منذ عام. تضع أرقام datasheet المنشورة محرك الأقراص الصلب الاستهلاكي قرب خطأ قراءة واحد غير قابل للاسترداد لكل 10^14 بت مقروءة، ومحرك enterprise 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. يشير الرقم الأكبر من الصفر في mirror إلى اختلاف النصفين، ولا يستطيع kernel تحديد أيهما صحيح، لأن أياً من النسختين لا يحتوي على checksum. بعض حالات عدم التطابق غير ضارة، وتكون swap partitions مصدرها المعتاد: فقد يكتب kernel صفحة تتغير تحته. أما ارتفاع العدد في مصفوفة بيانات فيعني ضرورة استبدال محرك الأقراص.

لماذا يعتمد مزودو VPS معيارياً على RAID 10 مع NVMe

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

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

كما تدفع أحجام المحركات في الاتجاه نفسه. فكلما كبر حجم المحركات، طال وقت إعادة البناء، وفي parity تكون هذه هي الفترة التي يصبح فيها كل شيء بطيئاً ولا تكون فيها أي بيانات محمية. وهذا هو السبب نفسه الذي يجعل عمليات نشر 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 هو جهاز المصفوفة وحالتها ومستواها.
  • الأسماء التي تليه هي الأعضاء. الرقم بين القوسين المربعين هو فهرس الجهاز في بيانات تعريف المصفوفة، وليس موضعه في السطر، وليس بالضرورة رقم slot الخاص به.
  • بعد استبدال محرك، يحتفظ العضو الجديد عادةً بفهرس أعلى من slot الذي يشغله، لذلك قد يكون nvme4n1p3[4] موجوداً في slot 2. يطبع mdadm --detail الـslot الفعلي في العمود RaidDevice، لذا استخدمه عندما يكون الفرق مهماً.
  • ظهور (F) بعد عضو يعني أنه معطوب. أما (S) فيعني أنه spare: موجود لكنه غير نشط وينتظر تعطل شيء ما.
  • 3906764800 blocks super 1.2 هو الحجم القابل للاستخدام بوحدات كتل 1 KiB، ثم تنسيق بيانات التعريف.
  • 512K chunks 2 near-copies هو حجم stripe chunk وتخطيط RAID 10، الذي يحتفظ هنا بنسختين من كل كتلة بجوار بعضهما.
  • [4/4] هو عدد الأعضاء الذي تتوقعه المصفوفة، ثم عدد الأعضاء المتزامنة حالياً.
  • [UUUU] هو محرف واحد لكل slot، بترتيب الـslots. U هو slot يعمل ومتزامن. _ هو slot لا يعمل فيه شيء.
  • bitmap: هو write intent 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] يعني أن slot واحداً من أصل أربعة لا يساهم في المصفوفة. ويحدد [UU_U] أي slot هو، لأن الشرطة السفلية هي المحرف الثالث، ولأن ترقيم الـslots يبدأ من الصفر، فهذا يعني أن slot 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 هي عملية scrub التي شغّلتها أعلاه. يوضح الزوج بين القوسين التقدم بوحدات كتل 1 KiB مقارنةً بالإجمالي لكل جهاز، أما finish فهو تقدير kernel للوقت المتبقي بالسرعة الحالية. تحدد /proc/sys/dev/raid/speed_limit_min وspeed_limit_max الحد الأقصى لهذه السرعة، وُضعت هذه الحدود حتى لا تحرم إعادة البناء عمليات I/O الخاصة بالإنتاج من الموارد.

عمود mdadm --detail كامل أثناء إعادة البناء
/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

عمود Number هو فهرس بيانات التعريف المطبوع بين القوسين في /proc/mdstat. وعمود RaidDevice هو الـslot، أي الموضع في السلسلة [UU_U]. يختلفان هنا لأن الجهاز 4 استبدل المحرك الذي كان يشغل slot 2. يحدد set-A وset-B نصفي كل mirror، ولذلك يجب ألا تفقد معاً عضواً من set-A وعضواً من set-B في الزوج نفسه اللذين يحتويان على البيانات نفسها.

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

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 10 قرصاً إلى قرص آخر وتترك الأزواج الأخرى دون تغيير. ويدفع الموفرون ثمن ذلك من السعة: نصف سعة NVMe الخام.

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

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

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

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

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

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