Miklix

உபுண்டுவில் ஒரு mdadm Array-யில் ஒரு தோல்வியுற்ற இயக்ககத்தை மாற்றுதல்

வெளியிடப்பட்டது: 15 பிப்ரவரி, 2025 அன்று பிற்பகல் 10:03:23 UTC

நீங்கள் ஒரு mdadm RAID வரிசையில் டிரைவ் செயலிழந்துவிடும் என்ற அச்சத்தில் இருந்தால், உபுண்டு கணினியில் அதை எவ்வாறு சரியாக மாற்றுவது என்பதை இந்தக் கட்டுரை விளக்குகிறது.


இந்தப் பக்கம் முடிந்தவரை பலருக்கு அணுகக்கூடியதாக இருக்க வேண்டும் என்பதற்காக ஆங்கிலத்திலிருந்து இயந்திர மொழிபெயர்ப்பு செய்யப்பட்டது. துரதிர்ஷ்டவசமாக, இயந்திர மொழிபெயர்ப்பு இன்னும் முழுமையான தொழில்நுட்பமாக இல்லை, எனவே பிழைகள் ஏற்படலாம். நீங்கள் விரும்பினால், அசல் ஆங்கிலப் பதிப்பை இங்கே காணலாம்:

Replacing a Failed Drive in an mdadm Array on Ubuntu

இந்தப் பதிவில் உள்ள தகவல்கள் Ubuntu 18.04 மற்றும் v4.1-rc1 எழுதும் நேரத்தில் அதன் களஞ்சியங்களில் சேர்க்கப்பட்டுள்ள mdadm பதிப்பை அடிப்படையாகக் கொண்டவை. இது மற்ற பதிப்புகளுக்கு செல்லுபடியாகலாம் அல்லது செல்லுபடியாகாமல் இருக்கலாம்.

சமீபத்தில் என்னுடைய ஹோம் ஃபைல் சர்வரில் திடீரென டிரைவ் செயலிழந்தது. இது ஒரு mdadm RAID-6 வரிசையில் ஒன்பது டிரைவ்களைக் கொண்டுள்ளது. அது எப்போதும் பயமாக இருக்கிறது, ஆனால் அதிர்ஷ்டவசமாக மறுகட்டமைப்பைத் தொடங்குவதற்காக மறுநாள் ஏற்கனவே வழங்கப்பட்ட மாற்று டிரைவை விரைவாகப் பெற முடிந்தது.

நான் முதலில் கோப்பு சேவையகத்தை அமைத்தபோது கொஞ்சம் மலிவானவன் என்பது ஒப்புக்கொள்ளத்தக்கது; இரண்டு டிரைவ்கள் மட்டுமே உண்மையான NAS டிரைவ்கள் (சீகேட் அயர்ன்வுல்ஃப்), மீதமுள்ளவை டெஸ்க்டாப் டிரைவ்கள் (சீகேட் பாராகுடா). ஆச்சரியப்படுவதற்கில்லை, கிட்டத்தட்ட மூன்று வருட சேவைக்குப் பிறகு கைவிட்ட டெஸ்க்டாப் டிரைவ்களில் இதுவும் ஒன்று. அது முற்றிலும் செயலிழந்து போயிருந்தது; அதை ஒரு டெஸ்க்டாப் 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 தொகுப்பை நிறுவ வேண்டும்)

பின்னர் சீரியல் எண்ணை டிரைவ்களில் உள்ள இயற்பியல் லேபிளில் உள்ள சீரியல் எண்களுடன் ஒப்பிட்டு, எது தோல்வியடைந்தது என்பதைக் கண்டறியலாம்.

இந்த முறை, எனக்கு அவ்வளவு அதிர்ஷ்டம் இல்லை. டிரைவ் முற்றிலும் செயலிழந்து, ஸ்மார்ட் அல்லது சீரியல் எண் உட்பட பிற தரவை வழங்க மறுத்துவிட்டது.

எனக்கு சர்வருக்கான நேரடி அணுகல் இருந்ததாலும் (நீங்களே ஒரு இயற்பியல் இயக்ககத்தை மாற்றப் போகிறீர்கள் என்றால் இது உங்களுக்குத் தேவை என்று நினைக்கிறேன் ;-)) வட்டு செயலிழந்தபோது சர்வர் உண்மையில் இயங்கிக் கொண்டிருந்ததாலும் (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 சாதனத்தைப் பற்றி கருத்து தெரிவிப்பது நல்லது, இதனால் Ubuntu அடுத்த துவக்கத்தில் அதை தானாக ஏற்ற முயற்சிக்காது, ஏனெனில் அது 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

இதற்கு சிறிது நேரம் ஆகலாம்; எனது குறைந்த சர்வரில் (பெரும்பாலும் நுகர்வோர் தர வன்பொருள் மற்றும் டெஸ்க்டாப் டிரைவ்களை அடிப்படையாகக் கொண்டது, நினைவில் கொள்ளுங்கள்) இது 100 MB/sec க்கும் குறைவாகவே எட்ட முடிந்தது. இது RAID-6 என்பதை நினைவில் கொள்ளுங்கள், எனவே மறுகட்டமைப்பில் நிறைய சமநிலை கணக்கீடுகள் உள்ளன; ஒரு RAID-10 மிக வேகமாக இருந்திருக்கும். இந்த குறிப்பிட்ட இயந்திரத்தில் AMD A10 9700E குவாட் கோர் CPU உள்ளது ("E" அதாவது இது ஒரு குறைவான கடிகார ஆற்றல் திறன் கொண்ட மாதிரி, அதாவது சூப்பர் ஃபாஸ்ட் அல்ல), என்ன எதிர்பார்க்கலாம் என்பது பற்றிய ஒரு யோசனையை உங்களுக்கு வழங்குவதற்காக. எனது அமைப்பில் ஒன்பது 8 TB டிரைவ்களுடன், முழு மறுகட்டமைப்பு 24 மணிநேரத்திற்கு மேல் ஆனது.

மறுகட்டமைப்பின் போது, ​​நீங்கள் கோப்பு முறைமையை வரிசையில் ஏற்றலாம் மற்றும் நீங்கள் விரும்பினால் அதை வழக்கம் போல் பயன்படுத்தலாம், ஆனால் அது முடியும் வரை அதை மறுகட்டமைப்பிற்கு விட்டுவிட விரும்புகிறேன். ஒரு டிரைவ் தோல்வியடைந்தால், மற்றொரு டிரைவ் விரைவில் தொடரக்கூடும் என்பதை நினைவில் கொள்ளுங்கள், எனவே மறுகட்டமைப்பை முடிந்தவரை விரைவாக முடிக்க விரும்புகிறீர்கள், அந்த நேரத்தில் மற்றொரு டிரைவ் தோல்வியடையக்கூடாது என்று நீங்கள் விரும்புகிறீர்கள். எனவே, கண்டிப்பாக அவசியமில்லாத பிற IO களுடன் அதைச் சுமக்க வேண்டாம்.

அது முடிந்ததும், அதை உங்கள் /etc/fstab கோப்பில் மீண்டும் சேர்த்து, மறுதொடக்கம் செய்து உங்கள் கோப்புகளை அனுபவிக்கவும் :-)

ப்ளூஸ்கையில் பகிரவும்பேஸ்புக்கில் பகிரவும்LinkedIn இல் பகிரவும்Tumblr இல் பகிரவும்X இல் பகிரவும்LinkedIn இல் பகிரவும்பின்டரஸ்டில் பின் செய்யவும்

மிக்கேல் பேங் கிறிஸ்டென்சன்

எழுத்தாளர் பற்றி

மிக்கேல் பேங் கிறிஸ்டென்சன்
மிக்கல் என்பவர் miklix.com இன் படைப்பாளர் மற்றும் உரிமையாளர் ஆவார். அவருக்கு 20 ஆண்டுகளுக்கும் மேலான தொழில்முறை கணினி நிரலாளர்/மென்பொருள் உருவாக்குநராக அனுபவம் உள்ளது, மேலும் தற்போது ஒரு பெரிய ஐரோப்பிய ஐடி நிறுவனத்தில் முழுநேரப் பணியாளராக உள்ளார். வலைப்பதிவு செய்யாதபோது, ​​அவர் தனது ஓய்வு நேரத்தை பரந்த அளவிலான ஆர்வங்கள், பொழுதுபோக்குகள் மற்றும் செயல்பாடுகளில் செலவிடுகிறார், இது இந்த வலைத்தளத்தில் உள்ளடக்கப்பட்ட பல்வேறு தலைப்புகளில் ஓரளவுக்கு பிரதிபலிக்கக்கூடும்.