धेरै नि:शुल्क RAM, NVMe Intel P4500 र सबै कुरा एकदमै ढिलो छ - स्वैप विभाजनको असफल थपको कथा

यस लेखमा, म एउटा अवस्थाको बारेमा कुरा गर्नेछु जुन हालसालै हाम्रो VPS क्लाउडमा सर्भरहरू मध्ये एउटा भएको थियो, जसले मलाई धेरै घण्टाको लागि स्टम्प छोड्यो। मैले लगभग 15 वर्षको लागि लिनक्स सर्भरहरू कन्फिगर र समस्या निवारण गरिरहेको छु, तर यो मामला मेरो अभ्यासमा फिट छैन - मैले धेरै गलत धारणाहरू बनाएको छु र मैले समस्याको कारण सही रूपमा निर्धारण गर्न र यसलाई समाधान गर्न सक्षम हुनु अघि अलि निराश भएँ। ।

प्रस्तावना

हामी एक मध्यम आकारको क्लाउड सञ्चालन गर्छौं, जुन हामीले निम्न कन्फिगरेसनको साथ मानक सर्भरहरूमा निर्माण गर्छौं - 32 कोर, 256 GB RAM र 4500TB PCI-E Intel P4 NVMe ड्राइभ। हामीलाई यो कन्फिगरेसन साँच्चै मनपर्छ किनभने यसले VM उदाहरण प्रकार स्तरमा सही प्रतिबन्ध प्रदान गरेर IO ओभरहेडको बारेमा चिन्ता गर्ने आवश्यकतालाई हटाउँछ। किनभने NVMe इंटेल P4500 प्रभावशाली कार्यसम्पादन छ, हामी एकै साथ शून्य IOWAIT भएको ब्याकअप सर्भरमा मेसिनहरूमा पूर्ण IOPS प्रावधान र ब्याकअप भण्डारण प्रदान गर्न सक्छौं।

हामी ती पुराना विश्वासीहरू मध्ये एक हौं जसले VM भोल्युमहरू भण्डारण गर्न हाइपरकन्भर्ज्ड SDN र अन्य स्टाइलिश, फेसनशील, युवा वस्तुहरू प्रयोग गर्दैनन्, विश्वास गर्दै कि प्रणाली जति सरल छ, "मुख्य गुरु गएको छ" को अवस्थामा समस्या निवारण गर्न सजिलो छ। पहाडहरूमा।" नतिजाको रूपमा, हामी 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 GB/सेकेन्ड प्रशोधन गर्न सक्षम छैनन्, जुन हाइपरभाइजर होस्टहरूले सजिलैसँग गर्न सक्छन्। उत्पादन गर्न।

माथिको प्रतिलिपि गर्ने प्रक्रिया थप कथाको लागि धेरै महत्त्वपूर्ण छ, विवरणहरू सहित - द्रुत Intel P4500 ड्राइभ प्रयोग गरेर, NFS प्रयोग गरेर र सम्भवतः ZFS प्रयोग गरेर।

ब्याकअप कथा

प्रत्येक हाइपरभाइजर नोडमा हामीसँग 8 जीबी साइजको सानो SWAP विभाजन छ, र हामी हाइपरभाइजर नोड आफै प्रयोग गरेर "रोल आउट" गर्छौं। DD सन्दर्भ छविबाट। सर्भरहरूमा प्रणाली भोल्युमको लागि, हामी LSI वा HP हार्डवेयर नियन्त्रकमा 2xSATA SSD RAID1 वा 2xSAS HDD RAID1 प्रयोग गर्छौं। सामान्यतया, हामी भित्र के छ वास्ता गर्दैनौं, किनकि हाम्रो प्रणाली भोल्युम SWAP बाहेक "लगभग पढ्न मात्र" मोडमा काम गर्दछ। र जब हामीसँग सर्भरमा धेरै RAM छ र यो 30-40% नि: शुल्क छ, हामी SWAP बारे सोच्दैनौं।

ब्याकअप प्रक्रिया। यो कार्य यस्तो देखिन्छ:

#!/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 RAIDs को साथ धेरै लिगेसी नोडहरू छन्, तिनीहरूका लागि यो सान्दर्भिक छ, त्यसैले तिनीहरू सर्दै छन्। AS IS। समग्रमा, यो कोडको एक रोचक टुक्रा हो जसले व्यर्थताको व्याख्या गर्दछ ionice यस्तो कन्फिगरेसन को मामला मा।

झण्डामा ध्यान दिनुहोस् iflag=direct लागि DD। पढ्दा IO बफरहरूको अनावश्यक प्रतिस्थापनबाट बच्न हामी बफर क्यासलाई बाइपास गरेर प्रत्यक्ष IO प्रयोग गर्छौं। तर, oflag=direct हामीले यसलाई प्रयोग गर्दा ZFS कार्यसम्पादन समस्याहरूको सामना गरेका कारणले होइन।

हामीले यो योजनालाई कुनै समस्या बिना धेरै वर्षदेखि सफलतापूर्वक प्रयोग गर्दै आएका छौं।

र त्यसपछि सुरु भयो... हामीले पत्ता लगायौं कि एउटा नोड अब ब्याकअप गरिएको छैन, र अघिल्लो 50% को एक राक्षसी IOWAIT संग चलिरहेको थियो। प्रतिलिपि बनाउँदैन किन बुझ्न प्रयास गर्दा, हामीले निम्न घटनाको सामना गर्यौं:

Volume group "images" not found

हामीले सोच्न थाल्यौं "Intel P4500 को लागि अन्त आएको छ," यद्यपि, ड्राइभलाई प्रतिस्थापन गर्न सर्भर बन्द गर्नु अघि, यो अझै ब्याकअप गर्न आवश्यक थियो। हामीले LVM2 ब्याकअपबाट मेटाडेटा पुनर्स्थापना गरेर LVM2 फिक्स गर्यौं:

vgcfgrestore images

हामीले ब्याकअप सुरु गर्यौं र यो तेल चित्रकला देख्यौं:

फेरि हामी धेरै दुःखी थियौं - यो स्पष्ट थियो कि हामी यसरी बाँच्न सक्दैनौं, किनकि सबै VPS हरू पीडित हुनेछन्, जसको मतलब हामीले पनि कष्ट भोग्नेछौं। के भयो पूर्ण अस्पष्ट छ - iostat दयनीय IOPS र उच्चतम IOWAIT देखायो। त्यहाँ "NVMe प्रतिस्थापन गरौं" बाहेक अरू कुनै विचारहरू थिएनन्, तर समयमै एउटा अन्तरदृष्टि भयो।

अवस्थाको चरण-दर-चरण विश्लेषण

ऐतिहासिक पत्रिका। केहि दिन पहिले, यो सर्भर मा 128 GB RAM संग ठूलो VPS सिर्जना गर्न आवश्यक थियो। त्यहाँ पर्याप्त मेमोरी भएको देखिन्छ, तर सुरक्षित पक्षमा हुनको लागि, हामीले स्वैप विभाजनको लागि अर्को 32 GB आवंटित गर्यौं। VPS सिर्जना गरिएको थियो, सफलतापूर्वक यसको कार्य पूरा भयो र घटना बिर्सियो, तर SWAP विभाजन रह्यो।

कन्फिगरेसन सुविधाहरू। सबै क्लाउड सर्भरहरूको लागि प्यारामिटर vm.swappiness पूर्वनिर्धारित रूपमा सेट गरिएको थियो 60। र SWAP SAS HDD RAID1 मा सिर्जना गरिएको थियो।

के भयो (सम्पादकहरूका अनुसार)। ब्याकअप गर्दा DD धेरै लेखन डाटा उत्पादन गर्यो, जुन NFS मा लेख्नु अघि RAM बफरहरूमा राखिएको थियो। प्रणाली कोर, नीति द्वारा निर्देशित swappiness, VPS मेमोरीका धेरै पृष्ठहरू स्वैप क्षेत्रमा सार्दै थियो, जुन ढिलो HDD RAID1 भोल्युममा अवस्थित थियो। यसले IOWAIT धेरै बलियो रूपमा बढ्यो, तर IO NVMe को कारणले होइन, तर IO HDD RAID1 को कारणले।

समस्या कसरी हल भयो। 32GB स्वैप विभाजन असक्षम गरिएको थियो। यसले 16 घण्टा लियो; तपाईं कसरी र किन SWAP यति बिस्तारै बन्द हुन्छ भन्ने बारे छुट्टै पढ्न सक्नुहुन्छ। सेटिङहरू परिवर्तन गरिएको छ swappiness बराबरको मूल्यमा 5 सबै बादलमा।

यो कसरी हुन सकेन ?। पहिलो, यदि SWAP SSD RAID वा NVMe उपकरणमा भएको थियो, र दोस्रो, यदि त्यहाँ कुनै NVMe उपकरण थिएन, तर एक ढिलो उपकरण जसले डाटाको यस्तो मात्रा उत्पादन गर्दैन - विडम्बनाको रूपमा, समस्या भयो किनभने त्यो NVMe धेरै छिटो छ।

त्यस पछि, सबै कुरा पहिले जस्तै काम गर्न थाले - शून्य IOWAIT संग।

स्रोत: www.habr.com