VPS-ல் ZFS scrub-ஐ எவ்வளவு அடிக்கடி இயக்க வேண்டும்?

ZFS scrub உண்மையில் என்ன செய்கிறது

ஒரு ZFS scrub, pool-ல் உள்ள அனைத்து allocated blocks-களையும் வாசித்து, அதன் checksum-ஐ மீண்டும் கணக்கிட்டு, parent block pointer-ல் சேமிக்கப்பட்டுள்ள checksum-உடன் ஒப்பிடுகிறது. இவை இரண்டும் பொருந்தவில்லை எனில், pool-ல் உள்ள redundancy-ஐப் பயன்படுத்தி ZFS அந்த block-ஐச் சரிசெய்கிறது. ZFS-ல் இந்த வேலையைச் செய்ய வேறெந்த வசதியும் இல்லை. சாதாரண வாசிப்பு செயல்பாடுகள் (ordinary reads) நீங்கள் அணுகும் blocks-களை மட்டுமே சரிபார்க்கும்; எனவே, இரண்டு ஆண்டுகளாக நீங்கள் திறக்காத ஒரு கோப்பு, scrub மூலம் வாசிக்கப்படும் வரை சரிபார்க்கப்படாமலேயே இருக்கும்.

Scrub என்பது fsck அல்ல, இது மற்ற கோப்பு முறைமைகளுக்குத் (filesystems) தேவைப்படும் offline repair pass போன்றது அல்ல. இதில் structural repair phase என்று எதுவும் இல்லை, ஏனெனில் ZFS வட்டில் உள்ள தரவு அமைப்பை (on-disk format) ஒருபோதும் சிதைந்த நிலையில் வைப்பதில்லை: ஒவ்வொரு எழுதும் செயல்பாடும் (write) புதிய இடத்திற்கே செல்லும், மேலும் pool-ன் root pointer ஆன uberblock இறுதியாகவே புதுப்பிக்கப்படும். Scrub முழு சாதனத்தையும் வாசிப்பதில்லை. இது allocated blocks-களை மட்டுமே வாசிக்கிறது, இதனால்தான் கிட்டத்தட்ட காலியாக உள்ள ஒரு pool சில நிமிடங்களில் scrub ஆகிவிடுகிறது, அதே pool 80% நிறைந்திருக்கும்போது அதிக நேரம் எடுத்துக்கொள்கிறது.

ZFS-ல் மிகக் குறைந்த I/O முன்னுரிமையில் (priority) இந்த scrub இயங்குகிறது. Linux-ல், zfs_vdev_scrub_max_active இயல்பாக 2 என அமைக்கப்பட்டுள்ளது, எனவே ஒரு vdev-க்கு (virtual device, ZFS ஒரு அலகாகக் கருதும் வட்டுக்களின் தொகுப்பு) அதிகபட்சம் இரண்டு scrub reads மட்டுமே ஒரே நேரத்தில் நடக்கும். zfs_scrub_min_time_ms இயல்பாக 750 என அமைக்கப்பட்டுள்ளது; இது transaction group flushes-க்கு இடையில், அதாவது ZFS எழுதும் தரவுகளைத் தொகுத்துச் சேமிக்கும் கால இடைவெளியில், scrub பணிக்காக sync thread செலவிடும் குறைந்தபட்ச நேரமாகும். பயன்பாட்டில் இல்லாத கணினியில், scrub முழு வட்டு வேகத்தையும் பயன்படுத்தும். கணினி சுமையில் இருக்கும்போது, இது தானாகவே ஒதுங்கிக்கொள்ளும். ஒன்று அல்லது இரண்டு வட்டுக்களைக் கொண்ட pool-ல் ஒதுங்குவதற்கு வேறு இடம் இல்லை என்பதால், அறுபது வட்டுக்களைக் கொண்ட பெரிய chassis-ஐ விட, இத்தகைய சிறிய அமைப்புகளில் scheduling மிகவும் முக்கியமானது.

தன்னால் சரிசெய்து கொள்ள முடியாத ஒரு pool-ஐ ஏன் scrub செய்ய வேண்டும்?

சிறிய pool-களில் மற்ற அனைத்து முடிவுகளையும் தீர்மானிக்கும் வாக்கியம் இதுதான். Redundancy இல்லாதபோது, ஒரு scrub சிதைவைக் கண்டறியும், ஆனால் அதைச் சரிசெய்ய முடியாது. VPS-ல் உள்ள ஒரு ஒற்றை virtual disk என்பது mirror அல்லது parity இல்லாத ஒரு pool ஆகும். ZFS அந்தப் பழுதடைந்த block-ஐ வாசிக்கும்போது, checksum தோல்வியடையும், அதை CKSUM column-ல் கணக்கிடும், அந்தப் கோப்பின் பெயரைத் தெரிவிக்கும், அதோடு நின்றுவிடும். ஏனெனில், மீண்டும் கட்டமைப்பதற்கு இரண்டாவது நகல் அங்கு இல்லை.

தெரிந்துகொள்ள வேண்டிய இரண்டு பகுதி விதிவிலக்குகள் உள்ளன. ZFS இயல்பாகவே metadata-வின் கூடுதல் நகலைச் சேமித்து வைக்கிறது (redundant_metadata=all). இது சாதனத்தின் வேறொரு பகுதியில் எழுதப்படுவதால், ஒரு சாதனத்தைக் கொண்ட pool-லிலும் பழுதடைந்த directory entry அல்லது block pointer-ஐ scrub மூலம் சரிசெய்ய முடியும். மேலும், copies=2 கொண்ட ஒரு dataset அதன் data blocks-ன் இரண்டு நகல்களை வைத்திருக்கும், ஆனால் இதற்கு இருமடங்கு சேமிப்பு இடம் தேவைப்படும். சாதனம் முழுமையாகச் செயலிழந்துவிட்டால், இவை எதற்கும் பலனில்லை. copies property ஆவணங்கள் இதைப் பற்றி எச்சரிக்கின்றன: striped pool-ஐ உருவாக்கிவிட்டு, copies=2-ஐ அமைத்துவிட்டு, உங்களிடம் redundancy இருப்பதாக நம்ப வேண்டாம்.

எனவே, ஒற்றைச் சாதனத்தைக் கொண்ட pool-ல் scrub உங்களுக்கு ஒரு விஷயத்தை வழங்குகிறது: அது முன்கூட்டியே துல்லியமான அறிவிப்பைத் தருகிறது. இது அமைதியான சிதைவை (silent corruption) zpool status -v-ல் ஒரு கோப்பின் பெயராக மாற்றுகிறது; அப்போது உங்கள் backup-ல் அந்தப் கோப்பின் நல்ல நகல் இருக்கும். இது backup-ன் அவசியத்தை வலியுறுத்துகிறதே தவிர, scrub செய்வதைத் தவிர்க்கச் சொல்லவில்லை. ஒரு point-in-time image-க்கும், உண்மையான off-box நகலுக்கும் உள்ள வித்தியாசத்தை நீங்கள் இன்னும் முடிவு செய்யவில்லை என்றால், why a VPS snapshot is not a backup என்பதிலிருந்து தொடங்கவும். ஏனெனில், உங்களிடம் மற்றொரு இடத்தில் intact நகல் இருந்தால் மட்டுமே scrub-ன் முடிவு பயனுள்ளதாக இருக்கும்.

எந்தப் பிழையையும் கண்டறியாத ஒரு scrub-ம் ஒரு முடிவே. நீங்கள் நம்பப்போகும் தரவு சிதையாமல் உள்ளது என்பதை அது உறுதிப்படுத்துகிறது. ஒரு restore அல்லது migration செய்வதற்கு முன்னால் நீங்கள் தெரிந்துகொள்ள வேண்டியது இதுதான்.

சிறிய VPS pool-ஐ எவ்வளவு அடிக்கடி scrub செய்ய வேண்டும்?

மாதத்திற்கு ஒருமுறை என்பது சரியான இயல்புநிலை (default) ஆகும், மேலும் தொகுப்புகள் (packages) ஏற்கனவே இதையே கருதுகின்றன. Debian மற்றும் Ubuntu ஆகியவை ஒவ்வொரு மாதத்தின் இரண்டாவது ஞாயிற்றுக்கிழமையும் ஆரோக்கியமான pool-களை scrub செய்யும் cron job-ஐ வழங்குகின்றன. FreeBSD-ன் periodic அமைப்பு நாட்களின் வரம்பைப் பொறுத்து செயல்படுகிறது, மேலும் daily_scrub_zfs_default_threshold இயல்புநிலையாக 35 நாட்களைக் கொண்டுள்ளது, இது கையேட்டின்படி ஐந்து வாரங்களைக் குறிக்கிறது.

பரபரப்பான சிறிய pool-களில் வாராந்திர scrubbing செய்வது, அது தரும் பலனை விட அதிக செலவை ஏற்படுத்துகிறது. ஒன்று அல்லது இரண்டு சாதனங்கள் மட்டுமே இருக்கும்போது, scrubbing செயல்முறை உங்கள் application-ன் அதே queue-க்காக போட்டியிடுகிறது, மேலும் அதைச் சமாளிக்க கூடுதல் சாதனம் எதுவும் இல்லை. ஒரு VPS-ல் I/O அளவு வரையறுக்கப்பட்டது, எனவே scrubbing செலவிடும் reads-கள் உங்கள் database-க்கு கிடைக்காது. இந்தச் செலவை ஒப்பிடும்போது, வாராந்திர scrubbing மூலம் உங்களால் சரிசெய்ய முடியாத ஒரு பிழையைப் பற்றி அதிகபட்சம் மூன்று வாரங்களுக்கு முன்பே எச்சரிக்கை பெறலாம். scrubbing மலிவாக இருக்கும்போது மட்டுமே இந்த வர்த்தகம் அர்த்தமுள்ளதாக இருக்கும்.

நேரத்தைக் கணக்கிட்டு, பிறகு முடிவெடுங்கள். ஒருமுறை கைமுறையாக scrub செய்து, அது எவ்வளவு நேரம் எடுக்கிறது என்பதைக் கவனியுங்கள்.

1. அமைதியான மாலை நேரத்தில் sudo zpool scrub tank-ஐ இயக்கவும் மற்றும் zpool status-லிருந்து மொத்த நேரத்தைப் பதிவு செய்யவும்.
2. அது ஒரு மணி நேரத்திற்குள் முடிந்து, இரவு நேரத்தில் server சும்மா இருந்தால், வாராந்திர scrubbing-ஐ மேற்கொள்ளலாம்.
3. pool traffic-ஐக் கையாண்டுகொண்டிருக்கும்போது அது பல மணிநேரம் இயங்கினால், மாதத்திற்கு ஒருமுறை என்ற முறையிலேயே தொடரவும் மற்றும் தொகுக்கப்பட்ட job-ஐ அதைக் கவனிக்க விடவும்.
4. pool-ன் அளவு குறிப்பிடத்தக்க வகையில் அதிகரிக்கும் போதெல்லாம் நேரத்தைக் கணக்கிடுங்கள், ஏனெனில் scrub காலம் என்பது வட்டு கொள்ளளவை அல்ல, ஒதுக்கப்பட்ட தரவை அடிப்படையாகக் கொண்டது.

நீங்கள் எதைத் தேர்வு செய்தாலும், அதை உங்கள் பிற தொடர்ச்சியான server பணிகளுடன் சேர்த்து குறித்துக்கொள்ளுங்கள். package upgrades மற்றும் log rotation போன்ற அதே பட்டியலில் scrubbing-ஐயும் சேர்க்க வேண்டும்: மாதாந்திர Linux server பராமரிப்பு சரிபார்ப்புப் பட்டியல்-ஐப் பார்க்கவும்.

Scrub-ஐத் தொடங்குதல், இடைநிறுத்துதல் மற்றும் நிறுத்துதல்

sudo zpool scrub tank
sudo zpool status tank

இடைநிறுத்துதல் (pausing) மற்றும் நிறுத்துதல் (stopping) ஆகிய இரண்டும் வெவ்வேறு செயல்பாடுகள். தவறானதைத் தேர்ந்தெடுப்பது, நீங்கள் செய்த வேலையை மீண்டும் பல மணிநேரம் செய்ய வேண்டிய நிலைக்குத் தள்ளும்.

sudo zpool scrub -p tank
sudo zpool scrub tank
sudo zpool scrub -s tank

-p என்பது இடைநிறுத்தப் பயன்படுகிறது. இடைநிறுத்தப்பட்ட நிலை மற்றும் அதன் முன்னேற்றம் அவ்வப்போது வட்டில் (disk) சேமிக்கப்படும். எனவே, ஒரு pool-ஐ export செய்தாலோ அல்லது reboot செய்தாலோ, scrub இடைநிறுத்தப்பட்ட நிலையிலேயே இருக்கும். மீண்டும் zpool scrub கட்டளையை இயக்கினால், வட்டில் கடைசியாகச் சேமிக்கப்பட்ட இடத்திலிருந்து அது தொடரும். -s என்பது scrub-ஐ முழுமையாக நிறுத்திவிடும்; அடுத்தமுறை நீங்கள் scrub-ஐத் தொடங்கும்போது, அது முதல் முதலிலிருந்து தொடங்கும். உங்களுக்கு ஒரு மணிநேரம் வட்டின் வேகம் தேவைப்பட்டால் -p-ஐப் பயன்படுத்தவும். scrub-ஐ முழுமையாக நீக்க விரும்பினால் -s-ஐப் பயன்படுத்தவும்.

கூடுதலாக இரண்டு flags-களைத் தெரிந்துகொள்வது அவசியம். -w என்பது scrub முடியும் வரை காத்திருந்து, அதன் பிறகு கட்டுப்பாட்டைத் தரும். இது script-களில் பயன்படுத்த ஏற்றது, அப்போதுதான் அடுத்த கட்டம் முன்கூட்டியே தொடங்காது. -e என்பது zpool status -v மூலம் கண்டறியப்பட்ட தரவுப் பிழைகள் (data errors) உள்ள கோப்புகளை மட்டும் சரிபார்க்கும். காப்புப்பிரதியிலிருந்து (backup) மீட்டெடுக்கப்பட்ட ஒரு கோப்பு சரியாக உள்ளதா என்பதை உறுதிப்படுத்த இது விரைவான வழியாகும்.

ZFS ஒரு நேரத்தில் ஒரு pool-க்கு ஒரு scrub அல்லது resilver (சாதனத்தை மாற்றிய பின் நடக்கும் rebuild) மட்டுமே அனுமதிக்கும், ஏனெனில் இவை இரண்டுமே அதிக I/O-வைச் சார்ந்தவை. ஒரு சாதனம் resilver ஆகிக்கொண்டிருந்தால், உங்கள் scrub அதன் முறை வரும் வரை காத்திருக்கும்.

scrub இயங்கும்போது zpool status-ஐ வாசிப்பது எப்படி

sudo zpool status tank கட்டளையை இயக்கி, மற்றவர்களின் எண்களுடன் ஒப்பிடுவதற்குப் பதிலாக உங்கள் சொந்த எண்களை வாசியுங்கள். scrub இயங்கும்போது, scan: வரியானது scanned, issued, total, repaired, நிறைவடைந்த சதவீதம் மற்றும் மீதமுள்ள நேரம் ஆகிய விவரங்களைக் காட்டும்.

Scanned என்பது metadata கட்டமாகும்: ZFS பிளாக் மரத்தை (block tree) ஆய்வு செய்து, வாசிக்க வேண்டிய முகவரிகளைச் சேகரிக்கும். Issued என்பது தரவு கட்டமாகும்: வட்டு வரிசைப்படி (disk order) வரிசைப்படுத்தப்பட்டு, சாதனத்திற்கு அனுப்பப்பட்ட வாசிப்பு கோரிக்கைகள் இவை. Sorted scrub என்பதால்தான் இரண்டு counters உள்ளன; இதில் issued என்பதுதான் உண்மையான முன்னேற்றத்தைக் குறிக்கும். தொடக்கத்தில், scanned என்பது issued-ஐ விட மிக வேகமாக முன்னேறும், எனவே நேர மதிப்பீடு துல்லியமாக இருக்காது. முதல் பத்து சதவீதம் முடிந்த பிறகு மதிப்பீடு செய்யுங்கள்.

Repaired என்பது சரியான நகலிலிருந்து மீண்டும் எழுதப்பட்ட பைட்டுகளின் எண்ணிக்கையைக் குறிக்கும். redundancy இல்லாத pool-ல், scrub எதைக் கண்டறிந்தாலும் இந்த எண்ணிக்கை பூஜ்ஜியமாகவே இருக்கும்; இது முந்தைய கருத்தை நீங்கள் கண்காணிக்கக்கூடிய எண்ணாக மாற்றுகிறது.

அதன்பிறகு, ஒவ்வொரு சாதனத்திற்குமான நெடுவரிசைகளை வாசியுங்கள். READ மற்றும் WRITE ஆகியவை சாதனம் தாமாகவே அறிவித்த I/O பிழைகளைக் குறிக்கும். CKSUM என்பது checksum சரிபார்ப்பில் தோல்வியடைந்த பிளாக்குகளைக் குறிக்கும்; scrub-ன் முக்கிய நோக்கமே இந்த CKSUM நெடுவரிசையை நிரப்புவதுதான். ஆரோக்கியமாகத் தோன்றும் ஒரு சாதனத்தில் CKSUM பூஜ்ஜியத்திற்கு மேல் இருந்தால், அது உண்மையான பிழை: தரவு திரும்பப் பெறப்பட்டது, ஆனால் அது தவறாக வந்துள்ளது.

கடைசி வரி தீர்ப்பைக் குறிக்கும். errors: No known data errors என்பது தேர்ச்சி பெற்றதைக் குறிக்கும். மற்றவை இருந்தால் sudo zpool status -v tank கட்டளையை இயக்க வேண்டும்; இது கடைசி முழுமையான scrub-க்குப் பிறகு ஏற்பட்ட தரவுப் பிழைகளின் முழுப் பட்டியலையும், பாதிக்கப்பட்ட கோப்புப் பெயர்களையும் காட்டும். அந்த கோப்புகளை backup-லிருந்து மீட்டெடுத்து, sudo zpool clear tank கட்டளையை இயக்கி counters-ஐ reset செய்யவும், பிறகு மீண்டும் scrub செய்யவும். ஒவ்வொரு முழுமையான scrub-ம் அந்தப் பட்டியலை மீண்டும் உருவாக்கும், எனவே முழுமையான scrub-க்குப் பிறகு ஒரு கோப்புப் பெயர் பட்டியலில் இல்லை என்றால், அது நிரந்தரமாக நீக்கப்பட்டுவிட்டது என்று அர்த்தம்.

உங்கள் கணினியில் எந்த periodic scrub job உள்ளது?

ஒன்று இருப்பதாகவோ அல்லது ஒன்று மட்டுமே இருப்பதாகவோ கருத வேண்டாம். இயங்குதளம் மற்றும் தொகுப்பைப் பொறுத்து இதற்கான வழிமுறை மாறுபடும். Pool வடிவம் எல்லா இடங்களிலும் ஒரே மாதிரியாக இருப்பதால், அதைச் சுற்றியுள்ள கருவிகள் அவ்வாறு இல்லை என்பதை மறந்துவிடுவது எளிது. FreeBSD மற்றும் Linux-ல் ZFS செயல்படும் விதம் இங்கு முக்கியமான வேறுபாடாகும்.

FreeBSD-ல், இந்த job periodic அமைப்பில் இயங்குகிறது. இவற்றை /etc/periodic.conf-ல் அமைக்கவும்:

daily_scrub_zfs_enable="YES"
daily_scrub_zfs_pools="tank"
daily_scrub_zfs_default_threshold="35"

daily_scrub_zfs_pools என்பது pool பெயர்களின் space-separated பட்டியல் ஆகும். இதை காலியாக விட்டால், அனைத்து pool-களும் scrub செய்யப்படும். daily_scrub_zfs_default_threshold என்பது pool-க்கு குறிப்பிட்ட threshold இல்லாதபோது scrub-களுக்கு இடைப்பட்ட நாட்களின் எண்ணிக்கை ஆகும். manual-ல் இதற்கான default மதிப்பு 35 எனக் கொடுக்கப்பட்டுள்ளது. daily job தினமும் இயங்கும்; threshold காலம் முடிந்த பிறகு மட்டுமே அது scrub-ஐத் தொடங்கும்.

Linux-ல் இது உங்கள் distribution-ன் ZFS தொகுப்பைப் பொறுத்தது. சில அமைப்புகளில் இரண்டு வழிமுறைகளும் ஒரே நேரத்தில் இருக்கலாம். ஒவ்வொரு pool-க்கும் தனித்தனியான systemd timers, அதாவது zfs-scrub-monthly@tank.timer மற்றும் zfs-scrub-weekly@tank.timer உள்ளன; இவை ஒரு நேரத்தில் ஒரு pool-க்கு என enable செய்யப்படும். Debian மற்றும் Ubuntu-வில் /etc/cron.d/zfsutils-linux-ம் உள்ளது. இது மாதத்தின் இரண்டாவது ஞாயிற்றுக்கிழமை அன்று ONLINE நிலையில் உள்ள அனைத்து pool-களையும் scrub செய்யும் script-ஐ இயக்கும். எதையும் சேர்ப்பதற்கு முன் உங்களிடம் என்ன உள்ளது என்பதைச் சரிபார்க்கவும்:

systemctl list-timers 'zfs-*'
ls /etc/cron.d/ | grep -i zfs
sudo zpool history tank | grep scrub

zpool history என்பதே சரியான பதில். ஏனெனில் இது pool உண்மையில் தொடங்கிய scrub-களைத் தேதிகளுடன் பதிவு செய்கிறது. ஒரு மாதத்திற்கு இரண்டு scrub-கள் நடந்தால், இரண்டு வழிமுறைகளும் செயல்பாட்டில் உள்ளன என்று அர்த்தம்; அதில் ஒன்றை நீக்க வேண்டும். Timer-ஐ enable செய்ய:

sudo systemctl enable --now zfs-scrub-monthly@tank.timer

எந்தவொரு tunable அமைப்பை விடவும் காலி இடமே முக்கியமானது

ஒரு சிறிய pool-ல் scrub duration என்பது, எவ்வளவு தரவு சேமிக்கப்பட்டுள்ளது மற்றும் அது எவ்வளவு சிதறி உள்ளது என்பதைப் பொறுத்தது. pool-ஐ நிரப்புவது இந்த இரண்டு சிக்கல்களையும் மோசமாக்கும்.

OpenZFS வழிகாட்டுதலின்படி, pool-ன் காலி இடத்தை 10%-க்கு மேல் வைத்திருக்க வேண்டும். அதற்கு கீழே சென்றால், allocator பயன்படுத்தும் metaslabs எனப்படும் பகுதிகள் 4% காலி இடத்திற்கு கீழ் குறையத் தொடங்கும். அப்போது allocator, first-fit முறையிலிருந்து best-fit முறைக்கு மாறும். Best-fit முறை அதிக CPU-வை பயன்படுத்தும். இதனால் write latency அதிகரிக்கும், fragmentation ஏற்படும். அடுத்த scrub இன்னும் மெதுவாக நடக்கும், ஏனெனில் அதே அளவு தரவு இப்போது அதிக எண்ணிக்கையிலான சிறிய reads-ஆகக் கிடைக்கும்.

எனவே, முதல் தீர்வு எந்தவொரு tunable அமைப்பும் அல்ல; தேவையற்றவற்றை நீக்குவதே ஆகும். ZFS-ல் பழைய snapshots-தான் பெரும்பாலும் இடத்தைப் பிடிக்கும். அதைத் தொடர்ந்து யாரும் நீக்காத Docker images மற்றும் layers மற்றும் மேம்படுத்தல்களுக்குப் பிறகு எஞ்சியிருக்கும் kernel packages ஆகியவை காரணமாக இருக்கலாம். வேறு எதையும் தொடுவதற்கு முன் zfs list -o space-ஐ இயக்கவும், ஏனெனில் இது snapshots பிடித்துள்ள இடத்தையும், நேரடித் தரவு பிடித்துள்ள இடத்தையும் பிரித்துக் காட்டும்.

இப்போது, knobs பற்றி சுருக்கமாகப் பார்ப்போம். Linux-ல் தற்போதைய மதிப்புகளை இவ்வாறு படிக்கலாம்:

cat /sys/module/zfs/parameters/zfs_scrub_min_time_ms
cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active

FreeBSD-ல் இதே அளவுருக்கள் sysctl மூலம் கிடைக்கின்றன, எனவே sysctl -a | grep scrub மூலம் உங்கள் மதிப்புகளைக் கண்டறியலாம். இவற்றை அதிகரிப்பது scrub-ஐ விரைவாக முடிக்கும், ஆனால் உங்கள் application-ன் வேகத்தைக் குறைக்கும். இவற்றைக் குறைப்பது இதற்கு நேர்மாறாகச் செயல்படும். ஒன்று அல்லது இரண்டு சாதனங்களைக் கொண்ட pool-ல், எந்த அமைப்பும் இரண்டையும் சரிசெய்யாது, ஏனெனில் பகிர்ந்தளிக்க ஒரே ஒரு queue மட்டுமே உள்ளது. ஒரு knob எப்போதாவதுதான் வடிவமைப்புக் குறைபாட்டைச் சரிசெய்யும். மாதந்தோறும் நடக்கும் scrub பாதிப்பை ஏற்படுத்தினால், pool நிரம்பிவிட்டது அல்லது சாதனம் மிகவும் மெதுவாக உள்ளது என்று அர்த்தம்; ஒரு tunable அமைப்பால் சிக்கலைத் தள்ளிப்போட மட்டுமே முடியும்.

Scrub நேரம் என்பது உங்கள் resilver-க்கான முன்கூட்டிய மதிப்பீடு

ஒரு resilver என்பது scrub செய்யும் அதே பணியைச் செய்கிறது: இது ஒதுக்கப்பட்ட blocks-களை வாசித்து, அவற்றைச் சரிபார்த்து, விடுபட்டவற்றை மாற்று சாதனத்தில் (replacement device) எழுதுகிறது. எனவே, உங்கள் scrub எடுத்துக்கொள்ளும் நேரமே, ஒரு rebuild எவ்வளவு காலம் எடுக்கும் என்பதற்கும், அந்தச் செயல்பாட்டின் போது pool எவ்வளவு காலம் குறைந்த redundancy-உடன் இயங்கும் என்பதற்கும் மிக நெருக்கமான மற்றும் உண்மையான மதிப்பீடாகும்.

ZFS ஆனது scrub பணியை விட resilver பணியை அதிக தீவிரத்துடன் திட்டமிடுகிறது, எனவே ஒரு rebuild பொதுவாக அதே pool-ன் scrub-ஐ விட விரைவாக முடிவடையும். உங்கள் scrub நேரத்தை ஒரு பாதுகாப்பான மேல் எல்லையாகக் (upper bound) கருதுங்கள். ஒரு scrub ஒன்பது மணிநேரம் எடுத்தால், அதே கால அளவில் ஒரு rebuild-ஐத் திட்டமிடுங்கள். அந்த கால இடைவெளிக்குள் இரண்டாவது சாதனம் செயலிழந்தால் pool-ஐ இழக்க நேரிடும் என்பதைப் புரிந்துகொள்ளுங்கள். இதற்காகத்தான் ஒரு பெரிய raidz group-க்கு பதிலாக mirrored pairs-ஐப் பயன்படுத்துவது நடைமுறைக்குச் சிறந்த வாதமாக உள்ளது. ஏனெனில், RAID 5-க்கு மாற்றாக ZFS பயன்படுத்தும் parity layout-ஆன raidz, மீதமுள்ள அனைத்து சாதனங்களையும் வாசிப்பதன் மூலமே rebuild செய்கிறது.

ஒரே சாதனத்தைக் கொண்ட pool-ல் resilver என்பதே கிடையாது. அந்தச் சாதனம் செயலிழந்தால், அதனுடன் pool-ம் செயலிழந்துவிடும். உங்கள் மீட்பு நேரம் (recovery time) என்பது உங்கள் restore நேரமே, எனவே restore செய்யும் நேரத்தை அளவிடுங்கள். நீங்கள் ஒருபோதும் செய்து பார்க்காத restore என்பது ஒரு மீட்புத் திட்டம் அல்ல.

வட்டு வாடகைக்கு எடுக்கும்போது என்ன மாற்றங்கள் நிகழ்கின்றன

VPS-ல் block device என்பது மெய்நிகரானது (virtual). Hypervisor ஒரு volume-ஐ வழங்குகிறது; அதன் அடியில் local NVMe அல்லது சொந்த parity கொண்ட replicated network volume இருக்கலாம். இதனால் scrubs செய்வதற்கு இரண்டு விளைவுகள் ஏற்படுகின்றன.

முதலாவதாக, தளத்தின் redundancy (மிகைத்தன்மை) ZFS-க்குத் தெரியாது, அதனால் ZFS-ஆல் அதைப் பயன்படுத்த முடியாது. உங்கள் அடியில் உள்ள media error-ஐ தளம் சரிசெய்தால், அந்தப் பிரச்சனை ZFS-க்குத் தெரியாது. ஒருவேளை தளம் தவறான block-ஐ வழங்கினால், ZFS அதைக் கண்டறியும், ஆனால் அதைச் சரிசெய்ய முடியாது. ஏனெனில், சரியான நகல் அந்த எல்லைக்கு அப்பால் உள்ளது.

இரண்டாவதாக, virtual disk-க்கு அடியில் உள்ள சாதனத்திற்கான SMART (self-monitoring, analysis and reporting technology) தரவுகளை உங்களால் பொதுவாகப் படிக்க முடியாது. எனவே, VPS-ல் வட்டு ஆரோக்கியத்தைக் கண்காணித்தல் சார்ந்த ஆரம்பக்கால எச்சரிக்கைகள் கிடைக்காமல் போகலாம். உங்கள் scrubs-லிருந்து கிடைக்கும் CKSUM counter-தான் நீங்கள் கவனிக்க வேண்டிய முக்கிய சமிக்ஞையாகும்.

ZFS வெறும் அறிக்கையை மட்டும் தராமல், பிழையைச் சரிசெய்ய வேண்டும் என நீங்கள் விரும்பினால், ஒரே instance-க்குள் ஒன்றுக்கும் மேற்பட்ட சாதனங்கள் தேவை. இது ஒரு tuning முடிவு அல்ல, திட்டமிடல் சார்ந்த முடிவாகும். சாதாரண VPS-க்கு பதிலாக storage VPS-ஐத் தேர்ந்தெடுப்பது உங்களுக்குத் தேவையான கொள்ளளவைத் தரும். ஆனால், அது இரண்டு தனித்தனி சாதனங்களைத் தருகிறதா என்பது உங்கள் திட்டத்தைப் பொறுத்தது. ஒரே volume-ன் இரண்டு துண்டுகளை mirror என நினைத்து உருவாக்காமல் இருக்க, lsblk-ஐ இயக்கி உறுதிப்படுத்திக் கொள்ளுங்கள். நாங்கள் Linux மற்றும் FreeBSD server-களை மட்டுமே வாடகைக்கு வழங்குகிறோம், நிர்வகிக்கப்படும் ZFS appliance-ஐ அல்ல. எனவே, scrub அட்டவணை மற்றும் backups-ஐ நீங்களே நிர்வகிக்க வேண்டும். இதுதான் இதற்கான ஒப்பந்தம்: pool-ன் முழுமையான கட்டுப்பாடு மற்றும் அதன் பராமரிப்புக்கான முழுப் பொறுப்பு உங்களுடையது.

FAQ

VPS-ல் ZFS pool-ஐ எவ்வளவு அடிக்கடி scrub செய்ய வேண்டும்?

சிறிய அளவிலான pool-களுக்கு மாதத்திற்கு ஒருமுறை scrub செய்வது போதுமானது. இது ஏற்கனவே உள்ள தொகுப்புகளின் (packages) செயல்பாட்டிற்கு இணங்க உள்ளது: Debian மற்றும் Ubuntu-வில் இரண்டாவது ஞாயிற்றுக்கிழமை cron job இயங்கும், FreeBSD-யின் periodic system-ல் 35 நாட்கள் இயல்புநிலை வரம்பாக உள்ளது. ஒருமுறை scrub செய்து முடிப்பதற்கு எவ்வளவு நேரம் ஆகிறது என்பதை அளவிட்டு, அது விரைவாக முடிவதை உறுதி செய்த பிறகு மட்டுமே வாராந்திர scrub-ஐ பரிசீலிக்கலாம். ஒன்று அல்லது இரண்டு சாதனங்களைக் கொண்ட பிஸியான pool-களில், வாராந்திர scrub-ஐச் செய்வது ஒவ்வொரு வாரமும் பயன்பாட்டு I/O-வை வீணடிக்கும், ஆனால் சில வாரங்களுக்கு முன்பே எச்சரிக்கை மட்டுமே கிடைக்கும்.

ஒற்றை வட்டு (single-disk) ZFS pool-ஐ scrub செய்வது பயனற்றதா?

இல்லை, அது உங்களுக்கு என்ன பலனைத் தருகிறது என்பதில் தெளிவாக இருக்க வேண்டும். தரவுத் தேக்கம் (redundancy) இல்லாத நிலையில், scrub-ஆல் சிதைவைக் கண்டறிய முடியுமே தவிர சரிசெய்ய முடியாது. இருப்பினும், ZFS இயல்பாகவே metadata-வின் கூடுதல் நகலை வைத்திருப்பதால், அதைச் சரிசெய்ய முடியும். இதன் மூலம் zpool status -v-ல் சேதமடைந்த கோப்புகளின் பட்டியலைப் பெறலாம். எங்காவது ஒரு நல்ல நகல் இருக்கும்போதே அவற்றை மீட்டெடுக்க இது உதவும். scrub உங்களுக்கு எந்தக் கோப்பை மீட்டெடுக்க வேண்டும் என்று துல்லியமாகக் கூறுவதால், சிறந்த backup முறைகளைப் பின்பற்றுவதே சரியான தீர்வாகும்.

ZFS scrub-ஐ இடைநிறுத்திவிட்டு பிறகு தொடர முடியுமா?

ஆம். zpool scrub -p tank கட்டளையைப் பயன்படுத்தி அதை இடைநிறுத்தலாம். இடைநிறுத்தப்பட்ட நிலை மற்றும் முன்னேற்றம் அவ்வப்போது வட்டில் எழுதப்படுவதால், export அல்லது reboot செய்தாலும் scrub இடைநிறுத்தப்பட்ட நிலையிலேயே இருக்கும். கடைசியாக நின்ற இடத்திலிருந்து மீண்டும் தொடங்க zpool scrub tank கட்டளையை இயக்கவும். இதற்கு zpool scrub -s tank-ஐப் பயன்படுத்த வேண்டாம்: -s scrub-ஐ முழுமையாக நிறுத்திவிடும், அடுத்தமுறை scrub செய்யும்போது அது முதல் முதலிருந்து தொடங்கும்.

எனது ZFS scrub ஏன் மெதுவாக உள்ளது, அதை வேகப்படுத்த முடியுமா?

scrub நேரம் என்பது வட்டின் கொள்ளளவைச் சார்ந்தது அல்ல, அது ஒதுக்கீடு செய்யப்பட்ட தரவு மற்றும் சிதைவைச் (fragmentation) சார்ந்தது. 90% நிரம்பிய pool-ல், 4%-க்கும் குறைவாக காலியாக உள்ள metaslabs-கள் allocator-ஐ first-fit-லிருந்து best-fit-க்கு மாற்றும். இதனால் ஏற்படும் சிதைவு, scrub-ஐ பல சிறிய வாசிப்புகளாக (reads) மாற்றுகிறது. இடத்தைச் சுத்தம் செய்வது (freeing space) எந்தவொரு tunable மாற்றத்தை விடவும் அதிக பலன் தரும். நீங்கள் zfs_scrub_min_time_ms அல்லது zfs_vdev_scrub_max_active மதிப்புகளை உயர்த்தி, scrub-க்கு அதிக queue பங்களிப்பை வழங்கலாம். ஆனால் ஒன்று அல்லது இரண்டு சாதனங்களைக் கொண்ட pool-களில், இந்த பங்களிப்பு நேரடியாக உங்கள் application-ன் வேகத்தைக் குறைக்கும்.