நிறைய இலவச ரேம், NVMe Intel P4500 மற்றும் அனைத்தும் மிகவும் மெதுவாக உள்ளது - ஒரு ஸ்வாப் பகிர்வின் தோல்வியின் கதை

இந்தக் கட்டுரையில், எங்கள் VPS கிளவுட் சர்வரில் சமீபத்தில் ஏற்பட்ட ஒரு சூழ்நிலையைப் பற்றி பேசுவேன், இது பல மணிநேரம் என்னைத் தடுமாறச் செய்தது. நான் சுமார் 15 ஆண்டுகளாக லினக்ஸ் சேவையகங்களை உள்ளமைத்து சரிசெய்து வருகிறேன், ஆனால் இந்த வழக்கு எனது நடைமுறைக்கு பொருந்தாது - நான் பல தவறான அனுமானங்களைச் செய்து, சிக்கலின் காரணத்தை சரியாகக் கண்டறிந்து அதைத் தீர்க்கும் முன் கொஞ்சம் அவநம்பிக்கை அடைந்தேன். .

முன்னுரை

32 கோர்கள், 256 ஜிபி ரேம் மற்றும் 4500டிபி பிசிஐ-இ இன்டெல் பி4 என்விஎம் டிரைவ் - நாங்கள் நடுத்தர அளவிலான கிளவுட் ஒன்றை இயக்குகிறோம். இந்த உள்ளமைவை நாங்கள் மிகவும் விரும்புகிறோம், ஏனெனில் இது VM நிகழ்வு வகை மட்டத்தில் சரியான கட்டுப்பாட்டை வழங்குவதன் மூலம் IO மேல்நிலை பற்றி கவலைப்பட வேண்டிய தேவையை நீக்குகிறது. ஏனெனில் NVMe இன்டெல் P4500 ஈர்க்கக்கூடிய செயல்திறனைக் கொண்டுள்ளது, ஒரே நேரத்தில் இயந்திரங்களுக்கு முழு IOPS வழங்கல் மற்றும் காப்புப்பிரதி சேமிப்பகத்தை பூஜ்ஜிய IOWAIT கொண்ட காப்புப்பிரதி சேவையகத்திற்கு வழங்க முடியும்.

விஎம் தொகுதிகளை சேமிப்பதற்கு ஹைப்பர்கான்வெர்ஜ் செய்யப்பட்ட எஸ்டிஎன் மற்றும் பிற ஸ்டைலான, நாகரீகமான, இளமைப் பொருட்களைப் பயன்படுத்தாத பழைய விசுவாசிகளில் நாமும் ஒருவராக இருக்கிறோம். மலைகளுக்கு." இதன் விளைவாக, VM தொகுதிகளை QCOW2 வடிவத்தில் XFS அல்லது EXT4 இல் சேமித்து வைக்கிறோம், இது LVM2க்கு மேல் பயன்படுத்தப்படுகிறது.

நாங்கள் ஆர்கெஸ்ட்ரேஷனுக்குப் பயன்படுத்தும் தயாரிப்பின் மூலம் QCOW2 ஐப் பயன்படுத்த வேண்டிய கட்டாயத்தில் உள்ளோம் - Apache CloudStack.

காப்புப்பிரதியைச் செய்ய, வால்யூமின் முழுப் படத்தையும் LVM2 ஸ்னாப்ஷாட்டாக எடுத்துக்கொள்கிறோம் (ஆம், LVM2 ஸ்னாப்ஷாட்கள் மெதுவாக இருப்பதை நாங்கள் அறிவோம், ஆனால் Intel P4500 இங்கேயும் நமக்கு உதவுகிறது). நாங்கள் செய்கிறோம் lvmcreate -s .. மற்றும் உதவியுடன் dd நாங்கள் காப்பு பிரதியை ZFS சேமிப்பகத்துடன் தொலை சேவையகத்திற்கு அனுப்புகிறோம். இங்கே நாங்கள் இன்னும் சற்று முற்போக்கானவர்கள் - எல்லாவற்றிற்கும் மேலாக, ZFS சுருக்கப்பட்ட வடிவத்தில் தரவைச் சேமிக்க முடியும், மேலும் அதைப் பயன்படுத்தி விரைவாக மீட்டெடுக்கலாம் DD அல்லது தனிப்பட்ட VM தொகுதிகளைப் பயன்படுத்தி பெறவும் mount -o loop ....

நீங்கள், நிச்சயமாக, LVM2 தொகுதியின் முழுப் படத்தையும் அகற்ற முடியாது, ஆனால் கோப்பு முறைமையை இல் ஏற்றலாம் RO மற்றும் QCOW2 படங்களை நகலெடுக்கவும், இருப்பினும், XFS இதிலிருந்து மோசமாகிவிட்டது என்ற உண்மையை நாங்கள் எதிர்கொண்டோம், உடனடியாக அல்ல, ஆனால் கணிக்க முடியாத வகையில். ஹைப்பர்வைசர் ஹோஸ்ட்கள் வார இறுதி நாட்களில், இரவில் அல்லது விடுமுறை நாட்களில் திடீரென "ஒட்டிக்கொள்ளும்" போது, ​​அவை எப்போது நிகழும் என்பது தெளிவாகத் தெரியாத பிழைகள் காரணமாக எங்களுக்குப் பிடிக்காது. எனவே, XFSக்கு நாம் ஸ்னாப்ஷாட் மவுண்டிங்கைப் பயன்படுத்துவதில்லை RO தொகுதிகளை பிரித்தெடுக்க, முழு LVM2 தொகுதியையும் நகலெடுக்கிறோம்.

காப்புப்பிரதி சேவையகத்திற்கான காப்புப்பிரதியின் வேகமானது காப்புப்பிரதி சேவையகத்தின் செயல்திறனால் தீர்மானிக்கப்படுகிறது, இது சுருக்க முடியாத தரவுகளுக்கு சுமார் 600-800 MB/s ஆகும்; மேலும் வரம்பானது காப்புப்பிரதி சேவையகம் இணைக்கப்பட்டுள்ள 10Gbit/s சேனலாகும். கிளஸ்டருக்கு.

இந்த வழக்கில், 8 ஹைப்பர்வைசர் சேவையகங்களின் காப்பு பிரதிகள் ஒரே நேரத்தில் ஒரு காப்பு சேவையகத்தில் பதிவேற்றப்படும். இவ்வாறு, காப்புப் பிரதி சேவையகத்தின் வட்டு மற்றும் பிணைய துணை அமைப்புகள் மெதுவாக இருப்பதால், ஹைப்பர்வைசர் ஹோஸ்ட்களின் வட்டு துணை அமைப்புகளை ஓவர்லோட் செய்ய அனுமதிக்காது, ஏனெனில் அவை 8 ஜிபி/செகண்ட் எனச் சொல்லலாம், ஹைப்பர்வைசர் ஹோஸ்ட்கள் எளிதாகச் செயல்படுத்த முடியாது. உற்பத்தி.

மேலே உள்ள நகலெடுக்கும் செயல்முறையானது, விவரங்கள் உட்பட மேலும் கதைக்கு மிகவும் முக்கியமானது - வேகமான Intel P4500 இயக்ககத்தைப் பயன்படுத்துதல், NFS ஐப் பயன்படுத்துதல் மற்றும் அநேகமாக ZFSஐப் பயன்படுத்துதல்.

காப்பு கதை

ஒவ்வொரு ஹைப்பர்வைசர் முனையிலும் 8 ஜிபி அளவிலான சிறிய ஸ்வாப் பகிர்வு உள்ளது, மேலும் ஹைப்பர்வைசர் முனையையே "உருட்டுகிறோம்" DD குறிப்பு படத்திலிருந்து. சேவையகங்களில் கணினி தொகுதிக்கு, LSI அல்லது HP வன்பொருள் கட்டுப்படுத்தியில் 2xSATA SSD RAID1 அல்லது 2xSAS HDD RAID1 ஐப் பயன்படுத்துகிறோம். பொதுவாக, SWAP ஐத் தவிர்த்து, எங்கள் சிஸ்டம் வால்யூம் "கிட்டத்தட்ட படிக்க மட்டும்" பயன்முறையில் இயங்குவதால், உள்ளே என்ன இருக்கிறது என்பதைப் பற்றி நாங்கள் கவலைப்படுவதில்லை. சர்வரில் நிறைய ரேம் இருப்பதால், அது 30-40% இலவசம் என்பதால், ஸ்வாப் பற்றி நாங்கள் யோசிப்பதில்லை.

காப்பு செயல்முறை. இந்த பணி இது போல் தெரிகிறது:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

கவனம் செலுத்துங்கள் ionice -c3, உண்மையில், இந்த விஷயம் NVMe சாதனங்களுக்கு முற்றிலும் பயனற்றது, ஏனெனில் அவற்றுக்கான IO திட்டமிடல் பின்வருமாறு அமைக்கப்பட்டுள்ளது:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

இருப்பினும், எங்களிடம் வழக்கமான SSD RAIDகளுடன் பல மரபு முனைகள் உள்ளன, அவர்களுக்கு இது பொருத்தமானது, எனவே அவை நகர்கின்றன அப்படியே. ஒட்டுமொத்தமாக, இது பயனற்ற தன்மையை விளக்கும் ஒரு சுவாரஸ்யமான குறியீடு மட்டுமே ionice அத்தகைய கட்டமைப்பு ஏற்பட்டால்.

கொடியில் கவனம் செலுத்துங்கள் iflag=direct செய்ய DD. படிக்கும் போது தேவையில்லாமல் IO பஃபர்களை மாற்றுவதைத் தவிர்க்க, இடையக தற்காலிக சேமிப்பைத் தவிர்த்து நேரடி IO ஐப் பயன்படுத்துகிறோம். எனினும், oflag=direct ZFS ஐப் பயன்படுத்தும்போது செயல்திறன் சிக்கல்களை எதிர்கொண்டதால் நாங்கள் அவ்வாறு செய்யவில்லை.

இந்த திட்டத்தை நாங்கள் பல ஆண்டுகளாக எந்த பிரச்சனையும் இல்லாமல் வெற்றிகரமாக பயன்படுத்தி வருகிறோம்.

பின்னர் அது தொடங்கியது... முனைகளில் ஒன்று இனி காப்புப் பிரதி எடுக்கப்படவில்லை என்பதையும், முந்தையது 50% அசுரத்தனமான IOWAIT உடன் இயங்குவதையும் கண்டறிந்தோம். நகலெடுப்பது ஏன் நிகழவில்லை என்பதைப் புரிந்து கொள்ள முயற்சிக்கும்போது, ​​​​பின்வரும் நிகழ்வை நாங்கள் சந்தித்தோம்:

Volume group "images" not found

"இன்டெல் P4500 க்கு முடிவு வந்துவிட்டது" என்று நாங்கள் சிந்திக்கத் தொடங்கினோம், இருப்பினும், இயக்ககத்தை மாற்றுவதற்கு சேவையகத்தை அணைக்கும் முன், காப்புப்பிரதியைச் செய்ய வேண்டியது அவசியம். LVM2 காப்புப்பிரதியிலிருந்து மெட்டாடேட்டாவை மீட்டமைப்பதன் மூலம் LVM2 ஐ சரி செய்தோம்:

vgcfgrestore images

நாங்கள் காப்புப்பிரதியைத் தொடங்கினோம், இந்த எண்ணெய் ஓவியத்தைப் பார்த்தோம்:

மீண்டும் நாங்கள் மிகவும் சோகமாக இருந்தோம் - எல்லா VPS களும் பாதிக்கப்படுவதால், நாங்கள் இப்படி வாழ முடியாது என்பது தெளிவாகத் தெரிந்தது, அதாவது நாமும் பாதிக்கப்படுவோம். என்ன நடந்தது என்பது முற்றிலும் தெளிவாக இல்லை - iostat பரிதாபகரமான IOPS மற்றும் மிக உயர்ந்த IOWAIT ஐக் காட்டியது. "NVMe ஐ மாற்றுவோம்" என்பதைத் தவிர வேறு எந்த யோசனையும் இல்லை, ஆனால் சரியான நேரத்தில் ஒரு நுண்ணறிவு ஏற்பட்டது.

படிப்படியாக நிலைமையின் பகுப்பாய்வு

வரலாற்று இதழ். சில நாட்களுக்கு முன்பு, இந்த சேவையகத்தில் 128 ஜிபி ரேம் கொண்ட பெரிய VPS ஐ உருவாக்க வேண்டியது அவசியம். போதுமான நினைவகம் இருப்பதாகத் தோன்றியது, ஆனால் பாதுகாப்பான பக்கத்தில் இருக்க, ஸ்வாப் பகிர்வுக்கு மற்றொரு 32 ஜிபியை ஒதுக்கினோம். VPS உருவாக்கப்பட்டது, அதன் பணியை வெற்றிகரமாக முடித்தது மற்றும் சம்பவம் மறக்கப்பட்டது, ஆனால் SWAP பகிர்வு அப்படியே இருந்தது.

கட்டமைப்பு அம்சங்கள். அனைத்து கிளவுட் சேவையகங்களுக்கும் அளவுரு vm.swappiness இயல்புநிலையாக அமைக்கப்பட்டது 60. SWAP ஆனது SAS HDD RAID1 இல் உருவாக்கப்பட்டது.

என்ன நடந்தது (எடிட்டர்களின் கூற்றுப்படி). காப்புப் பிரதி எடுக்கும்போது DD நிறைய எழுதும் தரவை உருவாக்கியது, இது NFS க்கு எழுதும் முன் ரேம் பஃபர்களில் வைக்கப்பட்டது. சிஸ்டம் கோர், கொள்கையால் வழிநடத்தப்படுகிறது swappiness, VPS நினைவகத்தின் பல பக்கங்களை ஸ்வாப் பகுதிக்கு நகர்த்திக் கொண்டிருந்தது, இது மெதுவான HDD RAID1 தொகுதியில் இருந்தது. இது IOWAIT மிகவும் வலுவாக வளர வழிவகுத்தது, ஆனால் IO NVMe காரணமாக அல்ல, மாறாக IO HDD RAID1 காரணமாக.

பிரச்சனை எப்படி தீர்க்கப்பட்டது. 32ஜிபி ஸ்வாப் பகிர்வு முடக்கப்பட்டது. இதற்கு 16 மணிநேரம் ஆனது; SWAP எப்படி, ஏன் மெதுவாக அணைக்கப்படுகிறது என்பதைப் பற்றி தனியாகப் படிக்கலாம். அமைப்புகள் மாற்றப்பட்டுள்ளன swappiness சமமான மதிப்புக்கு 5 மேகம் முழுவதும்.

இது எப்படி நடக்காது?. முதலாவதாக, SWAP ஆனது SSD RAID அல்லது NVMe சாதனத்தில் இருந்தால், இரண்டாவதாக, NVMe சாதனம் இல்லை என்றால், ஆனால் மெதுவான சாதனம் அத்தகைய தரவை உருவாக்காது - முரண்பாடாக, NVMe மிக வேகமாக இருப்பதால் சிக்கல் ஏற்பட்டது.

அதன் பிறகு, எல்லாம் முன்பு போலவே வேலை செய்யத் தொடங்கியது - பூஜ்ஜிய IOWAIT உடன்.

ஆதாரம்: www.habr.com