Miklix

جایگزینی درایو ناموفق در آرایه mdadm در اوبونتو

منتشر شده: ۱۵ فوریهٔ ۲۰۲۵ ساعت ۲۲:۰۳:۱۴ (UTC)

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


این صفحه ماشینی از انگلیسی ترجمه شد تا در دسترس هر چه بیشتر مردم باشد. متأسفانه، ترجمه ماشینی هنوز یک فناوری کامل نشده است، بنابراین ممکن است خطاهایی رخ دهد. در صورت تمایل می توانید نسخه اصلی انگلیسی را در اینجا مشاهده کنید:

Replacing a Failed Drive in an mdadm Array on Ubuntu

اطلاعات این بر اساس اوبونتو 18.04 و نسخه mdadm موجود در مخازن آن است. در زمان نگارش این مقاله v4.1-RC1. ممکن است برای نسخه های دیگر معتبر باشد یا نباشد.

من اخیرا یک خرابی ناگهانی درایو در سرور فایل خانگی خود داشتم، که از 9 درایو در یک آرایه mdadm RAID-6 تشکیل شده است. این همیشه ترسناک است، اما خوشبختانه من توانستم به سرعت یک درایو جایگزین را تهیه کنم که روز بعد تحویل داده شده بود تا بتوانم بازسازی را شروع کنم.

مسلما زمانی که در ابتدا سرور فایل را راه اندازی کردم، کمی خیلی ارزان بودم. تنها دو تا از درایوها درایوهای NAS واقعی هستند (Seagate IronWolf)، در حالی که بقیه درایوهای دسکتاپ هستند (Seagate Barracuda). جای تعجب نیست که این یکی از درایوهای دسکتاپ بود که تسلیم شده بود (با این حال، پس از تقریبا سه سال خدمات). کاملا مرده بود. پس از انتقال آن به محفظه USB دسکتاپ، تنها چیزی که از آن بیرون آمدم صدای کلیک ناراحت کننده ای بود و نه اوبونتو 20.04 و نه ویندوز 10 نتوانستند آن را تشخیص دهند.

اوه خوب، در مورد قسمت جایگزین (و بله، درایو جدیدی که خریدم یک IronWolf بود، درس آموختم) - به همان اندازه که از دست دادن یک درایو در یک آرایه در حال اجرا ترسناک است، اگر روش صحیح تعویض آن را ندانید، ترسناک تر است. این اولین بار نیست که مجبور می شوم یک درایو خراب را در یک آرایه mdadm جایگزین کنم، اما خوشبختانه آنقدر نادر است که معمولا مجبورم دستورات مناسب را جستجو کنم. این بار تصمیم گرفتم راهنمای کوچک خودم را برای مراجعات بعدی تهیه کنم.

بنابراین، اول از همه، هنگامی که ایمیل رویداد شکست مخوف را از mdadm دریافت می کنید، باید شناسایی کنید که کدام درایو شکست خورده است. مطمئنا، نام دستگاه را به شما می گوید (در مورد من /dev/sdf)، اما احتمالا مشخص نیست که کدام درایو فیزیکی در واقع به عنوان این نام ها می توانند هنگام بوت شدن دستگاه تغییر کنند.

اگر حتی مطمئن نیستید که کدام نام دستگاه از کار افتاده است، می توانید از دستور زیر برای فهمیدن این موضوع استفاده کنید (/dev/md0 را با دستگاه RAID خود جایگزین کنید):

mdadm -–query -–detail /dev/md0

همانطور که گفته شد، در مورد من /dev/sdf بود، پس بیایید به آن ادامه دهیم.

سپس، می توانید با صدور این دستور، شماره سریال درایو شکست خورده را پیدا کنید:

smartctl -–all /dev/sdf | grep -i 'Serial'

(اگر SmartCTL یافت نشد، باید بسته smartmontools را در اوبونتو نصب کنید)

سپس می توان شماره سریال را با شماره سریال روی برچسب فیزیکی روی درایوها مقایسه کرد تا مشخص شود کدام یک شکست خورده است.

با این حال، این بار چندان خوش شانس نبودم. درایو کاملا مرده بود و حتی از ارائه SMART یا سایر داده ها از جمله شماره سریال خودداری کرد.

از آنجایی که من دسترسی فیزیکی به سرور داشتم (که اگر می خواهید خودتان یک درایو فیزیکی را جایگزین کنید، واقعا به آن نیاز دارید، فکر می کنم ;-)) و سرور در واقع در حال اجرا بود که دیسک از کار افتاد (و به لطف افزونگی RAID-6 به خوبی کار می کرد)، من با روش واقعا ابتدایی، اما در واقع بسیار موثر و واضح رفتم، که به سادگی یک فایل بزرگ را در سرور کپی می کنم و تماشا می کنم که کدام نور HDD سوسو نمی زند. در عرض چند ثانیه مقصر را شناسایی کردم.

اکنون، قبل از بیرون کشیدن درایو فیزیکی، ایده خوبی است که با صدور این دستور به طور رسمی mdadm را از این هدف مطلع کنید (نام دستگاه ها را در صورت لزوم با نام خود جایگزین کنید):

mdadm -–manage /dev/md0 -–remove /dev/sdf1

در صورت موفقیت، mdadm با پیامی پاسخ می دهد که درایو را "داغ" حذف کرده است، ظاهرا به این دلیل که دستگاه حمله مجازی در آن زمان در حال اجرا است.

اگر با یک پیام خطای مشابه "دستگاه یا منبع مشغول است" شکست بخورد، ممکن است mdadm در واقع درایو را ثبت نکرده باشد که به طور کامل از کار افتاده باشد. برای انجام این کار، این دستور را صادر کنید (دوباره، به یاد داشته باشید که نام دستگاه ها را با نام خود جایگزین کنید):

mdadm --manage /dev/md0 --fail /dev/sdf

پس از آن، باید بتوانید دستگاه را با دستور قبلی از آرایه حذف کنید.

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

اگرچه SATA به طور کلی باید از تعویض داغ پشتیبانی کند، اما من قصد نداشتم در این تنظیمات چیزی را به خطر بیندازم، بنابراین تصمیم گرفتم هنگام تعویض درایو، دستگاه را خاموش کنم.

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

پس از بوت کردن دستگاه با درایو جدید براق نصب شده، از lsblk یا روش های دیگری برای شناسایی آن استفاده کنید. اگر چیز دیگری را تغییر نداده اید، احتمالا (اما نه لزوما) همان نام درایوی را که تعویض کرده اید خواهد داشت. در مورد من این کار را کرد، بنابراین مورد جدید نیز /dev/sdf نامیده می شود.

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

من برای این منظور از sgdisk استفاده کردم و جدول پارتیشن را از /dev/sdc به /dev/sdf کپی کردم. مطمئن شوید که نام دستگاه ها را در صورت لزوم با نام خود مطابقت دهید.

به ترتیب در اینجا توجه کنید: ابتدا درایو "به" را لیست می کنید! این برای من کمی ضد شهودی است، اما فقط مطمئن شوید که آن را درست دریافت کرده اید تا خرابی درایو دیگری در آرایه نداشته باشید ;-)

sgdisk -R /dev/sdf /dev/sdc

سپس برای جلوگیری از تداخل UUID، UUID های جدید برای درایو جدید ایجاد کنید:

sgdisk -G /dev/sdf

و اکنون بالاخره زمان آن فرا رسیده است که درایو جدید را به آرایه اضافه کنیم و مهمانی بازسازی را شروع کنیم! (خوب، این واقعا یک مهمانی نیست، در واقع یک فرآیند کاملا آهسته و ناراحت کننده است زیرا شما واقعا نمی خواهید درایو دیگری در این زمان شکست بخورد. آبجو ممکن است کمک کند، گرچه)

به هر حال، برای افزودن درایو جدید به آرایه، این دستور را صادر کنید (دوباره، مطمئن شوید که نام دستگاه ها را با نام خود جایگزین کنید):

mdadm -–manage /dev/md0 -–add /dev/sdf1

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

می توانید به این صورت زیر نظر داشته باشید:

watch cat /proc/mdstat

این احتمالا مدتی طول خواهد کشید. در سرور Lowly من (عمدتا بر اساس سخت افزار درجه مصرف کننده و درایوهای دسکتاپ، توجه داشته باشید) توانست به کمتر از 100 مگابایت در ثانیه برسد. به خاطر داشته باشید که این RAID-6 است، بنابراین محاسبات برابری زیادی با بازسازی وجود دارد. RAID-10 بسیار سریعتر بود. این دستگاه خاص دارای یک پردازنده چهار هسته ای AMD A10 9700E است ("E" به این معنی است که یک مدل کم مصرف است، یعنی فوق العاده سریع نیست)، فقط برای اینکه به شما ایده بدهد که چه انتظاری دارید. با 9 درایو 8 ترابایتی در راه اندازی من، بازسازی کامل کمی بیش از 24 ساعت طول کشید.

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

پس از اتمام، آن را دوباره به فایل /etc/fstab خود اضافه کنید، راه اندازی مجدد کنید و از فایل های خود لذت ببرید :-)

در Bluesky به اشتراک بگذاریددر فیسبوک به اشتراک بگذاریددر لینکدین به اشتراک بگذاریددر Tumblr به اشتراک بگذاریددر X به اشتراک بگذاریددر لینکدین به اشتراک بگذاریدپین در پینترست

میکل بنگ کریستنسن

درباره نویسنده

میکل بنگ کریستنسن
مایکل خالق و صاحب miklix.com است. او بیش از 20 سال تجربه به عنوان یک برنامه نویس حرفه ای کامپیوتر / توسعه دهنده نرم افزار دارد و در حال حاضر به طور تمام وقت برای یک شرکت بزرگ فناوری اطلاعات اروپایی مشغول به کار است. هنگامی که وبلاگ نویسی نمی کند، اوقات فراغت خود را صرف مجموعه وسیعی از علایق، سرگرمی ها و فعالیت ها می کند، که ممکن است تا حدی در موضوعات مختلف پوشش داده شده در این وب سایت منعکس شود.