Miklix

উবুন্টুতে একটি mdadm অ্যারেতে একটি ব্যর্থ ড্রাইভ প্রতিস্থাপন করা হচ্ছে

প্রকাশিত: ১৫ ফেব্রুয়ারী, ২০২৫ এ ১০:০৩:১৮ PM UTC

যদি আপনি mdadm RAID অ্যারেতে ড্রাইভ ব্যর্থতার ভয়ঙ্কর পরিস্থিতিতে থাকেন, তাহলে এই নিবন্ধটি ব্যাখ্যা করবে কিভাবে উবুন্টু সিস্টেমে এটি সঠিকভাবে প্রতিস্থাপন করবেন।


এই পৃষ্ঠাটি যতটা সম্ভব মানুষের কাছে পৌঁছানোর জন্য ইংরেজি থেকে মেশিন অনুবাদ করা হয়েছে। দুর্ভাগ্যবশত, মেশিন অনুবাদ এখনও একটি নিখুঁত প্রযুক্তি নয়, তাই ত্রুটি হতে পারে। আপনি যদি চান, আপনি এখানে মূল ইংরেজি সংস্করণটি দেখতে পারেন:

Replacing a Failed Drive in an mdadm Array on Ubuntu

এই পোস্টের তথ্যগুলি উবুন্টু ১৮.০৪ এবং এর সংগ্রহস্থলে অন্তর্ভুক্ত mdadm এর সংস্করণের উপর ভিত্তি করে তৈরি; v4.1-rc1 লেখার সময়। এটি অন্যান্য সংস্করণের জন্য বৈধ হতে পারে আবার নাও হতে পারে।

সম্প্রতি আমার হোম ফাইল সার্ভারে হঠাৎ ড্রাইভ ফেইলিওর হয়েছে, যেটাতে mdadm RAID-6 অ্যারেতে নয়টি ড্রাইভ থাকে। এটা সবসময়ই ভয়াবহ, কিন্তু সৌভাগ্যবশত আমি দ্রুত একটি রিপ্লেসমেন্ট ড্রাইভ খুঁজে পেতে সক্ষম হয়েছি যা পরের দিনই ডেলিভারি করা হয়েছে যাতে আমি পুনর্নির্মাণ শুরু করতে পারি।

আমি যখন ফাইল সার্ভারটি সেটআপ করেছিলাম তখন আমার টেনশন একটু বেশিই ছিল, এটা স্বীকার করতেই হবে; এর মধ্যে মাত্র দুটি ড্রাইভই আসল NAS ড্রাইভ (Seagate IronWolf), বাকিগুলো ডেস্কটপ ড্রাইভ (Seagate Barracuda)। অবাক হওয়ার কিছু নেই যে, এটি এমন একটি ডেস্কটপ ড্রাইভ ছিল যা প্রায় তিন বছর ধরে কাজ করার পরও বন্ধ হয়ে গিয়েছিল। এটি সম্পূর্ণরূপে বন্ধ হয়ে গিয়েছিল; এটিকে একটি ডেস্কটপ USB এনক্লোজারে স্থানান্তর করার পর আমি কেবল একটি বিরক্তিকর ক্লিকিং শব্দ থেকে বেরিয়ে এসেছি এবং Ubuntu 20.04 বা Windows 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 একটি বার্তার মাধ্যমে উত্তর দেবে যে এটি ড্রাইভটি "হট রিমুভ" করেছে, সম্ভবত কারণ ভার্চুয়াল রেইড ডিভাইসটি আসলে সেই সময়ে চালু ছিল।

যদি এটি "device or resource busy" এর মতো একটি ত্রুটি বার্তা সহ ব্যর্থ হয়, তাহলে হতে পারে যে mdadm আসলে ড্রাইভটি সম্পূর্ণরূপে ব্যর্থ হওয়ার জন্য নিবন্ধিত করেনি। এটি করার জন্য, এই কমান্ডটি জারি করুন (আবার, যথাযথভাবে আপনার নিজস্ব ডিভাইসের নাম দিয়ে প্রতিস্থাপন করতে ভুলবেন না):

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

এর পরে, আপনি পূর্ববর্তী কমান্ডের সাহায্যে অ্যারে থেকে ডিভাইসটি সরাতে সক্ষম হবেন।

এখন ড্রাইভটি আসলেই প্রতিস্থাপন করার সময়। যদি আপনি সত্যিই, সত্যিই - সত্যিই, সত্যিই - নিশ্চিত হন যে আপনার মেশিন এবং কন্ট্রোলার হট সোয়াপিং সমর্থন করে, তাহলে আপনি মেশিনটি বন্ধ না করেই এটি করতে পারেন। এটিই হবে আসল, সঠিক সার্ভার হার্ডওয়্যারে চলমান গুরুত্বপূর্ণ প্রোডাকশন সিস্টেমগুলিকে এগিয়ে নেওয়ার উপায় যা আপনি জানেন যে এটি পরিচালনা করতে পারে। আমার হোম ফাইল সার্ভারটি একটি কনজিউমার গ্রেড ডেস্কটপ মাদারবোর্ডের উপর ভিত্তি করে তৈরি করা হয়েছে যেখানে PCIe স্লটে কয়েকটি সেমি-নোনমে SATA কন্ট্রোলার রয়েছে যাতে আরও SATA পোর্ট সরবরাহ করা যায়।

যদিও SATA সাধারণত হট সোয়াপিং সমর্থন করে , আমি এই সেটআপে কোনও ঝুঁকি নিতে চাইনি, তাই আমি ড্রাইভ প্রতিস্থাপন করার সময় মেশিনটি বন্ধ করার সিদ্ধান্ত নিয়েছি।

এটি করার আগে, /etc/fstab ফাইলে raid ডিভাইসটি মন্তব্য করে রাখা ভালো যাতে উবুন্টু পরবর্তী বুটে এটি স্বয়ংক্রিয়ভাবে মাউন্ট করার চেষ্টা না করে, কারণ এটি হ্যাং হয়ে যেতে পারে এবং RAID অ্যারের অবনতির কারণে আপনাকে পুনরুদ্ধার মোডে বাধ্য করতে পারে। যদি এটি একটি ডেস্কটপ সিস্টেম হয় তবে এটি একটি বড় সমস্যা নাও হতে পারে, তবে আমি মনিটর বা কীবোর্ড সংযুক্ত না করে এই সার্ভারটি হেডলেস চালাই, তাই এটি কিছুটা ঝামেলার হবে।

নতুন চকচকে ড্রাইভ ইনস্টল করে মেশিন বুট করার পর, lsblk অথবা অন্য কোন উপায়ে এটি সনাক্ত করুন। যদি আপনি অন্য কিছু পরিবর্তন না করে থাকেন, তাহলে সম্ভবত এটি (কিন্তু অগত্যা নয়) আপনার প্রতিস্থাপন করা ড্রাইভের মতো একই নাম পাবে। আমার ক্ষেত্রে এটি ছিল, তাই নতুনটিকে /dev/sdfও বলা হয়।

যেহেতু আমার অ্যারেটি ফিজিক্যাল ডিভাইসের পরিবর্তে পার্টিশনের উপর ভিত্তি করে তৈরি, তাই পার্টিশন টেবিলটি একটি কার্যকরী ড্রাইভ থেকে নতুন ড্রাইভে কপি করতে হয়েছিল যাতে নিশ্চিত করা যায় যে সেগুলি ঠিক একই রকম। আপনি যদি ফিজিক্যাল ডিভাইসে আপনার অ্যারে চালান, তাহলে আপনি এই ধাপটি এড়িয়ে যেতে পারেন।

আমি এই উদ্দেশ্যে sgdisk ব্যবহার করেছি, /dev/sdc থেকে /dev/sdf এ পার্টিশন টেবিলটি অনুলিপি করেছি। যথাযথভাবে আপনার নিজস্ব নামগুলির সাথে মেলে ডিভাইসের নামগুলি প্রতিস্থাপন করতে ভুলবেন না।

এখানে ক্রমটি লক্ষ্য করুন : প্রথমে "to" ড্রাইভটি তালিকাভুক্ত করুন! এটি আমার কাছে কিছুটা বিপরীতমুখী, তবে নিশ্চিত করুন যে আপনি এটি সঠিকভাবে করেছেন যাতে অ্যারেতে আপনার আর একটি ড্রাইভ ব্যর্থতা না হয় ;-)

sgdisk -R /dev/sdf /dev/sdc

তারপর UUID দ্বন্দ্ব এড়াতে, নতুন ড্রাইভের জন্য নতুন UUID তৈরি করুন:

sgdisk -G /dev/sdf

আর এখন অবশেষে সময় এসেছে অ্যারেতে নতুন ড্রাইভ যোগ করার এবং পুনর্নির্মাণ পার্টি শুরু করার! (ঠিক আছে, এটি আসলে কোনও পার্টি নয়, এটি আসলে বেশ ধীর এবং বিরক্তিকর প্রক্রিয়া কারণ আপনি সত্যিই চান না যে এই সময়ে আরেকটি ড্রাইভ ব্যর্থ হোক। তবে বিয়ার সাহায্য করতে পারে)

যাই হোক, অ্যারেতে নতুন ড্রাইভ যোগ করতে, এই কমান্ডটি জারি করুন (আবার, যথাযথভাবে ডিভাইসের নামগুলি আপনার নিজস্ব দিয়ে প্রতিস্থাপন করতে ভুলবেন না):

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

সবকিছু ঠিকঠাক থাকলে, ড্রাইভটি কোনও ঝামেলা ছাড়াই অ্যারেতে যোগ করা হবে। আমার বিশ্বাস এটি আসলে ডিফল্টরূপে "হট স্পেয়ার" হিসেবে যোগ করা হয়েছে, কিন্তু যেহেতু এই অ্যারেতে একটি ডিস্ক নেই (যেটি ব্যর্থ হয়েছে), তাই এটি অবিলম্বে ব্যবহার করা হবে এবং পুনর্নির্মাণ প্রক্রিয়া শুরু হবে।

আপনি এটির উপর এভাবে নজর রাখতে পারেন:

watch cat /proc/mdstat

এতে হয়তো কিছুটা সময় লাগবে; আমার নিম্নমানের সার্ভারে (মূলত কনজিউমার গ্রেড হার্ডওয়্যার এবং ডেস্কটপ ড্রাইভের উপর ভিত্তি করে), এটি ১০০ এমবি/সেকেন্ডেরও কম গতিতে পৌঁছাতে সক্ষম হয়েছে। মনে রাখবেন এটি RAID-6, তাই পুনর্নির্মাণের সাথে অনেক সমতা গণনা জড়িত; একটি RAID-10 অনেক দ্রুত হত। এই বিশেষ মেশিনটিতে একটি AMD A10 9700E কোয়াড কোর সিপিইউ রয়েছে ("E" মানে এটি একটি কম-ক্লকড এনার্জি সাশ্রয়ী মডেল, অর্থাৎ অতি দ্রুত নয়), কেবল আপনাকে কী আশা করা উচিত তার একটি ধারণা দেওয়ার জন্য। আমার সেটআপে নয়টি ৮ টিবি ড্রাইভ সহ, সম্পূর্ণ পুনর্নির্মাণে ২৪ ঘন্টারও বেশি সময় লেগেছে।

পুনর্নির্মাণের সময়, আপনি অ্যারেতে ফাইল সিস্টেমটি মাউন্ট করতে পারেন এবং যদি আপনি চান তবে এটি স্বাভাবিকভাবে ব্যবহার করতে পারেন, তবে আমি এটি পুনর্নির্মাণের উপর ছেড়ে দিতে পছন্দ করি যতক্ষণ না এটি সম্পন্ন হয়। মনে রাখবেন যে যদি একটি ড্রাইভ ব্যর্থ হয়, তবে শীঘ্রই অন্য একটি ড্রাইভও ব্যর্থ হতে পারে, তাই আপনি যত তাড়াতাড়ি সম্ভব পুনর্নির্মাণটি সম্পন্ন করতে চান কারণ আপনি সত্যিই চান না যে সেই সময় অন্য একটি ড্রাইভ ব্যর্থ হোক। অতএব, এটিকে অন্য IO দিয়ে বোঝাবেন না যা কঠোরভাবে প্রয়োজনীয় নয়।

এটি হয়ে গেলে, এটি আপনার /etc/fstab ফাইলে আবার যোগ করুন, রিবুট করুন এবং আপনার ফাইলগুলি উপভোগ করুন :-)

ব্লুস্কাইতে শেয়ার করুনফেসবুকে শেয়ার করুনলিংকডইনে শেয়ার করুনটাম্বলারে শেয়ার করুনX-এ শেয়ার করুনলিংকডইনে শেয়ার করুনপিন্টারেস্টে পিন করুন

মিকেল ব্যাং ক্রিস্টেনসেন

লেখক সম্পর্কে

মিকেল ব্যাং ক্রিস্টেনসেন
মিকেল হলেন miklix.com এর স্রষ্টা এবং মালিক। একজন পেশাদার কম্পিউটার প্রোগ্রামার/সফ্টওয়্যার ডেভেলপার হিসেবে তার ২০ বছরেরও বেশি অভিজ্ঞতা রয়েছে এবং বর্তমানে তিনি একটি বৃহৎ ইউরোপীয় আইটি কর্পোরেশনে পূর্ণকালীন কর্মরত। ব্লগিং না করার সময়, তিনি তার অবসর সময় বিভিন্ন আগ্রহ, শখ এবং কার্যকলাপে ব্যয় করেন, যা কিছুটা হলেও এই ওয়েবসাইটে কভার করা বিভিন্ন বিষয়ের মধ্যে প্রতিফলিত হতে পারে।