RAID 10 چیست و چرا برای سرور مجازی VPS مناسب است؟

RAID 10 چیست و چرا میزبان‌های VPS از آن استفاده می‌کنند

RAID 10 ساختار ذخیره‌سازی است که اکثر میزبان‌های VPS تحت درایوهای مجازی‌سازی‌شده NVMe (حافظه غیرفرار سریع) از آن استفاده می‌کنند. این ساختار هر درایو را روی یک جفت (partner) کپی (mirror) می‌کند و سپس داده‌ها را در میان این جفت‌های آینه‌ای توزیع (stripe) می‌کند. یک درایو می‌تواند بدون توقف آرایه از کار بیفتد و عملیات بازیابی، صرفاً یک کپی ساده از درایو سالم است، نه یک محاسبه مجدد که نیاز به خواندن تمام درایوهای دیگر مجموعه داشته باشد.

RAID مخفف redundant array of independent disks است. این فناوری تنها یک وظیفه دارد: فعال نگه‌داشتن ماشین در زمانی که یک دیسک خراب شده یا در حال تعویض است. این وظیفه، «در دسترس بودن» (availability) است و در دسترس بودن به معنای «امنیت» (safety) نیست.

RAID عملیات نوشتن شما را تکثیر می‌کند. rm -rf /srv یک عملیات نوشتن است. هر دو نیمه آینه، دایرکتوری را در همان میلی‌ثانیه حذف می‌کنند و آرایه پس از آن همچنان وضعیت خود را سالم گزارش می‌دهد.

این جمله را به خاطر بسپارید. باقی این صفحه به این می‌پردازد که هر سطح RAID در برابر چه چیزی مقاوم است و هزینه هر عملیات نوشتن در هر سطح چقدر است. بخش‌های پایانی شامل دستوراتی برای خواندن وضعیت آرایه در ماشینی است که مالک آن هستید، و همچنین به خرابی‌هایی می‌پردازد که RAID هرگز پوشش نداده است.

سطوحی که خریدار فضای میزبانی واقعاً با آن‌ها مواجه می‌شود: 1، 5، 6 و 10

صفحهٔ پلن‌ها عددی را ذکر می‌کند و در همان‌جا متوقف می‌شود. این عدد به دو پرسش پاسخ می‌دهد: چند درایو می‌توانند از کار بیفتند و هزینهٔ هر عملیات نوشتن چقدر است.

RAID 1 یک آینه (Mirror) است. دو درایو بلوک‌های یکسانی را نگه می‌دارند. هر عملیات نوشتن به هر دو درایو ارسال می‌شود. هر کدام از درایوها می‌توانند پاسخگوی عملیات خواندن باشند. یک درایو می‌تواند بدون از دست رفتن داده‌ها از کار بیفتد و نیمی از ظرفیت خام قابل استفاده است. هیچ parity برای محاسبه وجود ندارد، بنابراین مسیر نوشتن کوتاه است.

RAID 5 استرایپینگ (Striping) با یک بلوک parity در هر استرایپ است. با n درایو، شما ظرفیت n-1 درایو را دریافت می‌کنید و آرایه دقیقاً یک خرابی را تحمل می‌کند. Parity روی یک درایو اختصاصی قرار نمی‌گیرد. این بلوک در میان همه درایوها می‌چرخد، بنابراین هر درایو هم داده و هم parity را حمل می‌کند.

RAID 6 یک بلوک parity دوم و مستقل به هر استرایپ اضافه می‌کند که معمولاً P و Q نامیده می‌شوند. این سطح خرابی همزمان هر دو درایو را تحمل می‌کند. این موضوع بیش از آنچه به نظر می‌رسد اهمیت دارد، زیرا خرابی دوم معمولاً در حین تعمیر خرابی اول رخ می‌دهد.

RAID 10 یک استرایپ از آینه‌هاست. درایوها به صورت جفت آینه می‌شوند و داده‌ها در میان این جفت‌ها پخش می‌شوند. ظرفیت قابل استفاده نیمی از کل ظرفیت خام است، مشابه RAID 1، با این تفاوت که موازی‌سازی استرایپینگ نیز به آن افزوده شده است.

شما همچنین آن را به صورت RAID 1+0 خواهید دید که توصیف دقیق‌تری است: ابتدا آینه کردن، سپس استرایپ کردن روی آینه‌ها. RAID 0+1 ترتیب دیگر است، یعنی ابتدا استرایپ کردن و سپس آینه کردن دو استرایپ. این روش بدتر است، زیرا خرابی یک درایو باعث از دسترس خارج شدن کل یک استرایپ می‌شود و برای تعمیر باید کل سمت دیگر کپی شود.

لینوکس یک مورد خاص است که ارزش دانستن دارد. raid10 در هسته، به جای دو لایهٔ روی هم، یک شخصیت واحد دارد، بنابراین روی تعداد فردی از درایوها اجرا می‌شود و چیدمان‌هایی (near، far، offset) دارد که یک تنظیمات تو در تو نمی‌تواند بیان کند. به همین دلیل است که خط وضعیت در یک سیستم لینوکسی به جای نام بردن از دو آرایه، 2 near-copies را نشان می‌دهد.

[
  {
    "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 ترابایتی در RAID 5 مقدار 7 ترابایت فضای قابل استفاده و در RAID 10 مقدار 4 ترابایت فضا ارائه می‌دهند. این اختلاف به معنای پول واقعی است و به همین دلیل است که استفاده از parity همچنان پیشنهاد می‌شود. RAID 6 در هر الگویی، 2 خرابی را تحمل می‌کند. RAID 10 تنها 1 خرابی را تضمین می‌کند، زیرا خرابی دومِ خطرناک، همان خرابی است که روی جفتِ درایوی که قبلاً از کار افتاده رخ می‌دهد. این سطح تا 4 خرابی را تحمل می‌کند، مشروط بر اینکه هیچ دو خرابی‌ای در یک جفت مشترک نباشند، که این موضوع بیشتر به شانس بستگی دارد تا ویژگی طراحی.

هزینه هر سطح برای هر عملیات نوشتن

نوشتن روی یک mirror شامل دو عملیات نوشتن است که هم‌زمان به هر دو عضو ارسال می‌شود. نوشتن روی یک stripe دارای parity کار بیشتری می‌طلبد، زیرا بلوک parity برای آن stripe اکنون نادرست است و باید دوباره محاسبه شود.

کنترلر نمی‌تواند parity را تنها با استفاده از بلوک جدید محاسبه کند. ابتدا به بلوک داده قدیمی و بلوک parity قدیمی نیاز دارد. بنابراین، یک نوشتن تصادفی کوچک در RAID 5 به ترتیب شامل خواندن، خواندن، نوشتن و نوشتن می‌شود. RAID 6 یک syndrome دوم نیز برای نگهداری دارد، بنابراین همان عملیات نوشتن به خواندن، خواندن، خواندن، نوشتن، نوشتن و نوشتن تبدیل می‌شود.

[
  {
    "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 هزینه دارد. این اعداد تفاوت در تأخیر (latency) را به‌طور کامل نشان نمی‌دهند. دو عملیات نوشتن در mirror به‌صورت موازی انجام می‌شوند، بنابراین سیستم‌عامل مهمان منتظر کندترینِ آن دو می‌ماند. مسیر parity شامل یک عملیات خواندن است که باید پیش از محاسبه parity جدید به پایان برسد، بنابراین سیستم‌عامل مهمان ابتدا منتظر یک خواندن و سپس یک نوشتن می‌ماند که به‌صورت متوالی انجام می‌شوند. در یک میزبان شلوغ، آن عملیات خواندن در صف انتظار پشت I/O سایر پردازش‌ها قرار می‌گیرد.

یک استثنای مهم وجود دارد. نوشتنِ به‌اندازه‌ای بزرگ که یک stripe کامل را پر کند، نیازی به داده‌های قدیمی ندارد، زیرا تمام بلوک‌های آن stripe در حال جایگزینی هستند. Parity از آنچه در حافظه موجود است محاسبه می‌شود و هزینه به یک نوشتن اضافه کاهش می‌یابد. به همین دلیل است که RAID 5 در بنچمارک‌های ترتیبی (sequential) مناسب به نظر می‌رسد اما تحت بار ترکیبی از نوشتن‌های کوچک توسط چندین کاربر، عملکرد ضعیفی دارد. الگویی را تست کنید که واقعاً اجرا می‌کنید: بنچمارک صحیح دیسک VPS به معنای I/O تصادفی با عمق صف واقع‌بینانه است، نه یک dd بزرگ.

چرا بازسازی (rebuild) بخش خطرناک ماجراست

یک بازسازی parity باید درایو ازدست‌رفته را از روی تمام درایوهای دیگر بازسازی کند؛ بنابراین، این عملیات 7 درایو باقی‌مانده را از اولین بلوک تا آخرین بلوک می‌خواند. بازسازی RAID 10 تنها 1 را می‌خواند: یعنی فقط درایو همزاد (mirror) درایو خراب، و هیچ چیز دیگری خوانده نمی‌شود.

دو هزینه از این موضوع ناشی می‌شود. اولی زمان است، زیرا بازسازی توسط کندترین درایو باقی‌مانده و محاسبات parity محدود می‌شود. دومی بار کاری است. تمام درایوهای موجود در یک parity set در تمام طول این بازه زمانی درگیر هستند، بنابراین تمام guestها روی آن node تا پایان عملیات، تأخیر (latency) بیشتری را تجربه می‌کنند. در RAID 10، فقط یک جفت درگیر است و سایر جفت‌ها با سرعت عادی خود به کار ادامه می‌دهند.

در همین بازه زمانی، یک ریسک صحت داده نیز وجود دارد. یک آرایه RAID 5 با یک درایو خراب، دیگر هیچ افزونگی (redundancy) ندارد؛ بنابراین، یک سکتور غیرقابل‌خواندن در هر جای درایوهای باقی‌مانده، اکنون غیرقابل‌بازیابی است. بازسازی تنها عملیاتی است که تمام سکتورها را می‌خواند، حتی آن‌هایی که در یک سال گذشته هیچ‌کس به آن‌ها دست نزده است. ارقام منتشرشده در دیتاشیت‌ها، نرخ خطای خواندن غیرقابل‌بازیابی برای یک هارد دیسک مصرفی را حدود یک خطا در هر 10^14 بیت خوانده‌شده و برای یک درایو NVMe سازمانی، یک خطا در هر 10^17 بیت یا بهتر اعلام می‌کنند. این‌ها مشخصات سازنده هستند تا اندازه‌گیری‌های واقعی، اما همین نسبت توضیح می‌دهد که چرا هشدار قدیمی مبنی بر شکست خوردن بازسازی RAID 5 درباره دیسک‌های چرخان بزرگ نوشته شده بود و چرا این هشدار در مورد NVMe بسیار ضعیف‌تر است. استدلال مربوط به بار کاری (load) روی هر نوع رسانه‌ای صادق است.

خطاهای نهفته را پیش از آنکه بازسازی آن‌ها را پیدا کند، با استفاده از scrubbing شناسایی کنید. توزیع‌های Debian و Ubuntu یک scrub دوره‌ای برای آرایه‌های md ارائه می‌دهند، و مکانیزم آن بین نسخه‌ها متفاوت است؛ بنابراین بررسی کنید کدام نسخه را دارید و سپس یک pass را به‌صورت دستی اجرا کنید.

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 پس از پایان pass به idle بازمی‌گردد و mismatch_cnt باید 0 را نشان دهد. عددی بالاتر از صفر در یک mirror به این معنی است که دو نیمه با هم اختلاف دارند و kernel نمی‌تواند بگوید کدام‌یک درست است، زیرا هیچ‌کدام از نسخه‌ها checksum ندارند. برخی از این عدم تطابق‌ها بی‌خطر هستند و پارتیشن‌های swap معمول‌ترین منبع آن محسوب می‌شوند: kernel ممکن است صفحه‌ای را بنویسد که در زیر لایه در حال تغییر است. افزایش تعداد خطاها در یک آرایه داده، نشانه درایوی است که باید تعویض شود.

چرا ارائه‌دهندگان VPS از RAID 10 برای NVMe استفاده می‌کنند

یک گره hypervisor تنها یک workload را اجرا نمی‌کند. این گره ده‌ها مهمان (guest) نامرتبط را میزبانی می‌کند و I/O آن‌ها به‌صورت جریانی از نوشتن‌های کوچک و بدون محلی‌بودن (locality) با یکدیگر ترکیب می‌شود. این دقیقاً همان الگویی است که چرخهٔ read-modify-write در parity بیشترین هزینه را برای آن دارد و این همان الگویی است که یک گره اشتراکی در تمام طول روز با آن مواجه است.

رفتار بازسازی (rebuild) را نیز در نظر بگیرید تا انتخاب مشخص شود. خرابی یک درایو در یک گره مبتنی بر parity، سرعت تمام مهمان‌های روی آن سرور را برای ساعت‌ها کاهش می‌دهد. خرابی یک درایو در یک گره RAID 10 فقط یک جفت را کند می‌کند و عملیات کپی به‌صورت ترتیبی و با سرعت درایو انجام می‌شود. ارائه‌دهندگان در حال فروش تأخیر (latency) بدون جهش‌های ناگهانی هستند، بنابراین این پایداری را با فدا کردن ظرفیت می‌خرند: نیمی از ظرفیت خام NVMe صرف mirror می‌شود.

اندازهٔ درایوها نیز همین رویکرد را تقویت می‌کند. با بزرگ‌تر شدن درایوها، بازهٔ زمانی بازسازی طولانی‌تر می‌شود و در parity، این همان بازه‌ای است که همه چیز کند شده و هیچ حفاظتی وجود ندارد. به همین دلیل است که پیاده‌سازی‌های ZFS برای مجازی‌سازی، به‌جای استفاده از raidz گسترده، از poolهایی از vdevهای آینه‌ای (mirrored) استفاده می‌کنند: یک resilver در حالت mirror فقط بلوک‌های در حال استفاده را روی یک جفت کپی می‌کند.

هیچ‌کدام از این موارد به این معنی نیست که RAID 10 در همه جا انتخاب درستی است. یک مقصد پشتیبان‌گیری (backup target) با نوشتن‌های ترتیبی طولانی نوشته می‌شود و به‌ندرت خوانده می‌شود، بنابراین RAID 6 در آنجا گزینهٔ بهتری است. این پیکربندی دو خرابی را تاب می‌آورد و بخش عمده‌ای از ظرفیت را بازمی‌گرداند. این workload است که تصمیم می‌گیرد، نه عدد. برای برنامه‌ای که امروز انتخاب می‌کنید، رسانهٔ ذخیره‌سازی معمولاً اهمیت بیشتری نسبت به چیدمان (layout) روی آن دارد و جهش از SATA SSD به NVMe بزرگ‌تر از هر تفاوت RAID در هر دو رسانه است.

نحوه خواندن /proc/mdstat

این دستورات را روی دستگاهی اجرا کنید که مالک آرایه هستید: یک سرور اختصاصی، یک سیستم خانگی یا یک VPS با دو volume متصل که خودتان آن را اسمبل کرده‌اید. خروجی خود را بخوانید. بلوک‌های زیر نمونه‌هایی هستند که نوشته شده‌اند تا بتوانید شکل خروجی خود را با آن‌ها مطابقت دهید.

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 که هسته در حال اجرا بارگذاری کرده است را فهرست می‌کند. ظاهر شدن raid10 در آنجا به این معنی است که کد در دسترس است و نه چیزی بیشتر.
• md0 : active raid10 دستگاه آرایه، وضعیت آن و سطح (level) آن است.
• نام‌های بعد از آن، اعضای آرایه هستند. عدد داخل کروشه، ایندکس دستگاه در متادیتای آرایه است، نه موقعیت آن در خط و نه لزوماً اسلات آن.
• پس از تعویض درایو، عضو جدید معمولاً ایندکسی بالاتر از اسلاتی که پر می‌کند نگه می‌دارد، بنابراین nvme4n1p3[4] می‌تواند در اسلات 2 قرار بگیرد. mdadm --detail اسلات واقعی را در ستون RaidDevice چاپ می‌کند، پس وقتی تفاوت اهمیت دارد از آن استفاده کنید.
• (F) بعد از یک عضو به معنی معیوب بودن است. (S) به معنی spare است: موجود، بیکار، در انتظار خرابی چیزی.
• 3906764800 blocks super 1.2 اندازه قابل استفاده به بلوک‌های 1 KiB و سپس فرمت متادیتا است.
• 512K chunks 2 near-copies اندازه chunk استرایپ و طرح RAID 10 است که در اینجا دو کپی از هر بلوک را در کنار هم نگه می‌دارد.
• [4/4] تعداد اعضایی است که آرایه انتظار دارد، و سپس تعداد اعضایی که در حال حاضر همگام (sync) هستند.
• [UUUU] یک کاراکتر برای هر اسلات به ترتیب اسلات است. U اسلاتی است که فعال و همگام است. _ اسلاتی است که چیزی در آن کار نمی‌کند.
• bitmap: بیت‌مپ قصد نوشتن (write intent bitmap) است. این بخش ثبت می‌کند که کدام نواحی در حال نوشته شدن بوده‌اند، بنابراین اگر عضوی قطع شود و دوباره برگردد، فقط همان نواحی همگام‌سازی می‌شوند نه کل درایو.

معنی [4/3] و [UU_U] هنگام بروز مشکل

یک آرایه تخریب‌شده (degraded) به این شکل دیده می‌شود.

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 می‌خواند. نام unit بین نسخه‌ها تغییر کرده است، بنابراین به جای حدس زدن، آن را با دستور آخر پیدا کنید. اجرای --test بلافاصله یک پیام برای هر آرایه ارسال می‌کند. خالی بودن اینباکس پس از آن به این معنی است که مسیر ایمیل خراب است، بنابراین پیامی که واقعاً برایتان مهم است نیز به همان روش از دست می‌رفت.

هنگامی که یک جایگزین در حال بازسازی (rebuild) است، یک خط پیشرفت زیر آرایه ظاهر می‌شود.

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 تخمین هسته بر اساس سرعت فعلی است. آن سرعت توسط /proc/sys/dev/raid/speed_limit_min و speed_limit_max محدود شده است و این محدودیت‌ها وجود دارند تا بازسازی باعث گرسنگی I/O تولیدی نشود.

/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 رد می‌شود. قبل از افزودن درایو جدید، آن را طوری پارتیشن‌بندی کنید که با درایو قدیمی مطابقت داشته باشد.

What you can and cannot see from inside a VPS

Most guests cannot see the host's RAID, and that is by design. The hypervisor hands you one virtual disk. Whether that disk is carved out of a RAID 10 pool of NVMe drives or is sitting on one drive is a property of the host, and it does not show up inside your guest.

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

systemd-detect-virt prints kvm on a KVM guest, a container type such as lxc on a container, and none on bare metal. On a KVM guest you normally see a single vda or sda in lsblk, and no arrays in /proc/mdstat, because there are none inside the guest.

On a container based VPS the reading is not trustworthy. Containers share the host kernel and parts of /proc are not namespaced, so what you read there can describe the host rather than your slice of it. Treat none of it as a fact about your own storage. Ask the provider what the layout is, and get the answer in writing if it matters to you.

What you can check from inside is the behaviour of the disk you were given. Checking whether your VPS disk is really NVMe covers the commands that report something real, and what an SSD VPS actually includes covers what the label on the plan page is claiming.

آیا باید از RAID داخل VPS استفاده کرد؟

معمولاً خیر، و دلیل آن حوزه‌های خرابی (failure domains) است. اگر دو volume را به یک VPS متصل کنید و آن‌ها را با mdadm آینه‌سازی (mirror) کنید، ممکن است هر دو volume روی یک آرایه فیزیکی واحد، در یک گره (node) یکسان و پشت یک منبع تغذیه مشترک قرار داشته باشند. در این حالت، شما هزینه هر عملیات نوشتن را دو برابر می‌کنید تا افزونگی‌ای را به دست آورید که از قبل داشته‌اید، و همچنان با بروز همان یک خرابی اصلی، هر دو نسخه را از دست خواهید داد.

استفاده از RAID زمانی ارزشمند است که ارائه‌دهنده خدمات مستند کرده باشد که volumeها در حوزه‌های خرابی مجزا قرار دارند، یا زمانی که از یک سرور اختصاصی با درایوهایی استفاده می‌کنید که خودتان به آن‌ها دسترسی مستقیم دارید. در غیر این صورت، تلاش شما برای تهیه نسخه‌های پشتیبانی که از دستگاه خارج می‌شوند، نتیجه‌بخش‌تر خواهد بود.

مواردی که RAID از آن‌ها محافظت نمی‌کند

RAID تنها یک رویداد را پوشش می‌دهد: خرابی فیزیکی یک درایو. تمام موارد زیر عملیات نوشتن معتبر محسوب می‌شوند، بنابراین آرایه آن‌ها را روی تمام نسخه‌ها اعمال کرده و وضعیت خود را سالم گزارش می‌کند.

• حذف فایل. rm -rf در دایرکتوری اشتباه، یا یک اسکریپت استقرار (deploy script) که متغیری در مسیر آن مقداردهی نشده است. آرایه این عملیات را یک نوشتن قانونی تلقی کرده و آن را دو بار انجام می‌دهد.
• باج‌افزار. رمزنگاری، نوعی عملیات نوشتن است. یک آرایه سالم، نسخه رمزنگاری‌شده را روی هر دو نیمه mirror ذخیره می‌کند.
• برنامه معیوب. باگی که داده‌های نامعتبر (garbage) را در پایگاه داده شما می‌نویسد، همان داده‌های نامعتبر را روی درایو پشتیبان نیز کپی می‌کند.
• کل گره (node). میزبانی که از کار می‌افتد یا حسابی که به اشتباه مسدود می‌شود. یک آرایه می‌تواند کاملاً سالم باشد اما در عین حال غیرقابل دسترس بماند.
• خود شما، یک هفته بعد. فایلی که روز دوشنبه حذف کرده‌اید، از همان روز دوشنبه در تمام درایوها از بین رفته است. تنها نسخه‌ای که پیش از آن زمان تهیه شده باشد، می‌تواند آن را بازگرداند.

Snapshotها روی همان فضای ذخیره‌سازی نیز راه‌حل نهایی نیستند. آن‌ها در برابر حذف فایل کمک می‌کنند، اما با از بین رفتن آرایه‌ای که روی آن قرار دارند، آن‌ها نیز نابود می‌شوند. ویژگی‌ای که یک نسخه پشتیبان را به نسخه پشتیبان تبدیل می‌کند، این است که در جای دیگری قرار داشته باشد. پشتیبان‌گیری رمزنگاری‌شده خارج از سرور با restic نیمه دیگر این صفحه است: آرایه به شما کمک می‌کند تا با وجود خرابی یک درایو، سرویس‌دهی را ادامه دهید و restic داده‌های شما را زمانی که آسیب ناشی از عملیاتی بوده که آرایه با خوشحالی آن را انجام داده است، بازیابی می‌کند.

FAQ

آیا RAID 10 به این معنی است که نیازی به پشتیبان‌گیری ندارم؟

خیر. RAID 10 فقط در برابر خرابی فیزیکی یک درایو محافظت می‌کند. این سیستم هر عملیات نوشتن معتبر را بلافاصله روی هر دو نیمه آینه اعمال می‌کند، بنابراین حذف فایل یا فعالیت باج‌افزار در همان لحظه به درایو پشتیبان نیز منتقل می‌شود. پس از آن، آرایه وضعیت خود را سالم گزارش می‌دهد، زیرا از دیدگاه آن هیچ خطایی رخ نداده است. شما همچنان به نسخه‌های پشتیبانی نیاز دارید که خارج از دستگاه نگهداری شوند و باید گهگاه یکی از آن‌ها را بازیابی کنید تا از سلامت و کارایی آن‌ها مطمئن شوید.

چرا ارائه‌دهندگان VPS از RAID 10 به جای RAID 5 یا RAID 6 استفاده می‌کنند؟

دو دلیل وجود دارد که هر دو به عملیات نوشتن تصادفی کوچک مربوط می‌شوند. نوشتن داده‌های مبتنی بر parity مستلزم خواندن داده‌های قدیمی و parity قدیمی پیش از محاسبه parity جدید است؛ بنابراین یک عملیات نوشتن کوچک در RAID 5 هزینه 4 عملیات و در RAID 6 هزینه 6 عملیات را در پی دارد، در حالی که این هزینه در یک آینه (mirror) تنها 2 است. بازسازی (rebuild) در آرایه‌های مبتنی بر parity مستلزم خواندن تمام درایوهای سالم از ابتدا تا انتهاست که باعث کند شدن تمام ماشین‌های مجازی روی آن گره (node) برای چندین ساعت می‌شود، اما در RAID 10 بازسازی فقط شامل کپی کردن یک درایو به درایو دیگر است و سایر جفت‌ها بدون تغییر باقی می‌مانند. ارائه‌دهندگان این مزیت را با کاهش ظرفیت در دسترس، یعنی از دست دادن نیمی از فضای خام NVMe، خریداری می‌کنند.

عبارت [U_] یا [UU_U] در فایل /proc/mdstat به چه معناست؟

هر کاراکتر نشان‌دهنده یک اسلات در آرایه است که به ترتیب اسلات‌ها قرار گرفته‌اند. U به این معنی است که آن اسلات دارای یک عضو فعال و همگام‌سازی‌شده است. _ نشان می‌دهد که در آن اسلات هیچ عضو فعالی وجود ندارد. [U_] در یک آینه دو درایوی به این معنی است که اسلات دوم از دسترس خارج شده و دیگر هیچ افزونگی (redundancy) باقی نمانده است. این وضعیت را در کنار جفت‌های دیگر بخوانید؛ مثلاً [4/3] می‌گوید آرایه انتظار چهار عضو را دارد اما تنها سه عضو در دسترس است. ترتیب اسلات‌ها با ستون RaidDevice در mdadm --detail مطابقت دارد، نه با ترتیبی که نام دستگاه‌ها در آن خط ظاهر می‌شوند.

یک آرایه RAID 10 حداکثر چند درایو را می‌تواند از دست بدهد؟

یک درایو، بدون توجه به الگوی خرابی. فراتر از آن، بستگی به این دارد که خرابی‌ها در کدام بخش‌ها رخ دهند. هر جفت آینه می‌تواند یکی از دو عضو خود را از دست بدهد؛ بنابراین یک آرایه هشت درایوی می‌تواند تا چهار خرابی را تحمل کند، به شرطی که هیچ دو خرابی در یک جفت مشترک نباشند. اما اگر دو خرابی در یک جفت رخ دهد، آرایه از کار می‌افتد. برنامه‌ریزی خود را بر اساس عدد تضمین‌شده یعنی یک درایو قرار دهید و هر چیزی فراتر از آن را به عنوان شانس در نظر بگیرید، نه به عنوان یک لایه حفاظتی.

آیا باید دو volume را داخل VPS خود با استفاده از mdadm آینه (mirror) کنم؟

معمولاً خیر. دو volume متصل به یک VPS اغلب روی یک آرایه فیزیکی واحد در همان میزبان (host) قرار دارند؛ بنابراین آینه کردن آن‌ها فقط هزینه هر عملیات نوشتن را دو برابر می‌کند و در برابر هیچ خطایی که RAID خودِ میزبان پوشش نمی‌دهد، محافظت ایجاد نمی‌کند. این کار تنها زمانی ارزشمند است که ارائه‌دهنده مستنداتی ارائه دهد که نشان دهد این volumeها در دامنه‌های خرابی (failure domains) مجزا قرار دارند. در غیر این صورت، انرژی خود را صرف پشتیبان‌گیری‌هایی کنید که از دستگاه خارج می‌شوند.