बहुत सारी मुफ्त रैम, NVMe Intel P4500 और सब कुछ बेहद धीमा है - एक स्वैप विभाजन के असफल जोड़ की कहानी

इस लेख में, मैं उस स्थिति के बारे में बात करूंगा जो हाल ही में हमारे वीपीएस क्लाउड में एक सर्वर के साथ हुई, जिसने मुझे कई घंटों तक स्तब्ध कर दिया। मैं लगभग 15 वर्षों से लिनक्स सर्वरों को कॉन्फ़िगर और समस्या निवारण कर रहा हूं, लेकिन यह मामला मेरे अभ्यास में बिल्कुल भी फिट नहीं बैठता है - मैंने कई गलत धारणाएं बनाईं और समस्या का कारण सही ढंग से निर्धारित करने और इसे हल करने में सक्षम होने से पहले थोड़ा हताश हो गया। .

प्रस्तावना

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

हम उन पुराने विश्वासियों में से एक हैं जो वीएम वॉल्यूम को स्टोर करने के लिए हाइपरकन्वर्ज्ड एसडीएन और अन्य स्टाइलिश, फैशनेबल, युवा चीजों का उपयोग नहीं करते हैं, यह मानते हुए कि सिस्टम जितना सरल होगा, "मुख्य गुरु चला गया है" की स्थितियों में समस्या निवारण करना उतना ही आसान होगा। पहाड़ों पर।" परिणामस्वरूप, हम VM वॉल्यूम को XFS या EXT2 में QCOW4 प्रारूप में संग्रहीत करते हैं, जिसे LVM2 के शीर्ष पर तैनात किया जाता है।

हमें ऑर्केस्ट्रेशन के लिए उपयोग किए जाने वाले उत्पाद - अपाचे क्लाउडस्टैक द्वारा QCOW2 का उपयोग करने के लिए भी मजबूर किया जाता है।

बैकअप करने के लिए, हम LVM2 स्नैपशॉट के रूप में वॉल्यूम की पूरी छवि लेते हैं (हाँ, हम जानते हैं कि LVM2 स्नैपशॉट धीमे हैं, लेकिन इंटेल P4500 यहां भी हमारी मदद करता है)। क र ते हैं। lvmcreate -s .. और मदद से dd हम बैकअप कॉपी को ZFS स्टोरेज वाले रिमोट सर्वर पर भेजते हैं। यहां हम अभी भी थोड़े प्रगतिशील हैं - आखिरकार, ZFS डेटा को संपीड़ित रूप में संग्रहीत कर सकता है, और हम इसका उपयोग करके इसे जल्दी से पुनर्स्थापित कर सकते हैं DD या उपयोग करके अलग-अलग VM वॉल्यूम प्राप्त करें mount -o loop ....

बेशक, आप LVM2 वॉल्यूम की पूरी छवि नहीं हटा सकते हैं, लेकिन फ़ाइल सिस्टम को इसमें माउंट कर सकते हैं RO और QCOW2 छवियों को स्वयं कॉपी करें, हालाँकि, हमें इस तथ्य का सामना करना पड़ा कि XFS इससे खराब हो गया, और तुरंत नहीं, बल्कि अप्रत्याशित तरीके से। हम वास्तव में इसे पसंद नहीं करते हैं जब हाइपरवाइज़र सप्ताहांत में, रात में या छुट्टियों पर त्रुटियों के कारण अचानक "स्टिक" होस्ट करता है जो स्पष्ट नहीं होता है कि वे कब होंगे। इसलिए, XFS के लिए हम स्नैपशॉट माउंटिंग का उपयोग नहीं करते हैं RO वॉल्यूम निकालने के लिए, हम बस संपूर्ण LVM2 वॉल्यूम कॉपी करते हैं।

बैकअप सर्वर पर बैकअप की गति हमारे मामले में बैकअप सर्वर के प्रदर्शन से निर्धारित होती है, जो कि असम्पीडित डेटा के लिए लगभग 600-800 एमबी/एस है; एक और सीमक 10 जीबी/एस चैनल है जिसके साथ बैकअप सर्वर जुड़ा हुआ है क्लस्टर के लिए.

इस स्थिति में, 8 हाइपरवाइज़र सर्वर की बैकअप प्रतियां एक साथ एक बैकअप सर्वर पर अपलोड की जाती हैं। इस प्रकार, बैकअप सर्वर के डिस्क और नेटवर्क सबसिस्टम, धीमे होने के कारण, हाइपरवाइजर होस्ट के डिस्क सबसिस्टम को ओवरलोड नहीं होने देते हैं, क्योंकि वे आसानी से 8 जीबी/सेकेंड को प्रोसेस करने में सक्षम नहीं होते हैं, जिसे हाइपरवाइजर होस्ट आसानी से कर सकता है। उत्पादन करना।

उपरोक्त प्रतिलिपि प्रक्रिया आगे की कहानी के लिए बहुत महत्वपूर्ण है, जिसमें विवरण भी शामिल है - तेज़ इंटेल 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 RAID के साथ कई विरासत नोड हैं, उनके लिए यह प्रासंगिक है, इसलिए वे आगे बढ़ रहे हैं जैसा है. कुल मिलाकर, यह कोड का एक दिलचस्प टुकड़ा है जो निरर्थकता को समझाता है ionice ऐसी कॉन्फ़िगरेशन के मामले में.

झंडे पर ध्यान दें iflag=direct के लिए DD. पढ़ते समय IO बफ़र्स के अनावश्यक प्रतिस्थापन से बचने के लिए हम बफ़र कैश को दरकिनार करते हुए सीधे IO का उपयोग करते हैं। तथापि, oflag=direct हम ऐसा नहीं करते क्योंकि इसका उपयोग करते समय हमें ZFS प्रदर्शन समस्याओं का सामना करना पड़ा है।

हम कई वर्षों से बिना किसी समस्या के इस योजना का सफलतापूर्वक उपयोग कर रहे हैं।

और फिर यह शुरू हुआ... हमने पाया कि नोड्स में से एक का अब बैकअप नहीं लिया गया था, और पिछला 50% के भयानक IOWAIT के साथ चल रहा था। यह समझने की कोशिश करते समय कि नकल क्यों नहीं होती, हमें निम्नलिखित घटना का सामना करना पड़ा:

Volume group "images" not found

हमने "इंटेल P4500 का अंत आ गया है" के बारे में सोचना शुरू कर दिया, हालाँकि, ड्राइव को बदलने के लिए सर्वर को बंद करने से पहले, बैकअप करना अभी भी आवश्यक था। हमने LVM2 बैकअप से मेटाडेटा पुनर्स्थापित करके LVM2 को ठीक किया:

vgcfgrestore images

हमने एक बैकअप लॉन्च किया और इस तेल चित्रकला को देखा:

हम फिर से बहुत दुखी थे - यह स्पष्ट था कि हम इस तरह नहीं रह सकते थे, क्योंकि सभी वीपीएस पीड़ित होंगे, जिसका अर्थ है कि हम भी पीड़ित होंगे। जो हुआ वह पूरी तरह अस्पष्ट है - iostat दयनीय IOPS और उच्चतम IOWAIT दिखाया। "आइए एनवीएमई को बदलें" के अलावा कोई विचार नहीं था, लेकिन सही समय पर एक अंतर्दृष्टि घटित हुई।

चरण दर चरण स्थिति का विश्लेषण

ऐतिहासिक पत्रिका. कुछ दिन पहले इस सर्वर पर 128 जीबी रैम के साथ एक बड़ा वीपीएस बनाना जरूरी था। ऐसा लगता था कि पर्याप्त मेमोरी थी, लेकिन सुरक्षित रहने के लिए, हमने स्वैप विभाजन के लिए अतिरिक्त 32 जीबी आवंटित किया। VPS बनाया गया, सफलतापूर्वक अपना कार्य पूरा किया गया और घटना को भुला दिया गया, लेकिन SWAP विभाजन बना रहा।

विन्यास विशेषताएं. सभी क्लाउड सर्वर के लिए पैरामीटर vm.swappiness डिफ़ॉल्ट पर सेट किया गया था 60. और SWAP SAS HDD RAID1 पर बनाया गया था।

क्या हुआ (संपादकों के अनुसार). बैकअप लेते समय DD बहुत सारा लेखन डेटा तैयार किया गया, जिसे एनएफएस पर लिखने से पहले रैम बफ़र्स में रखा गया था। सिस्टम कोर, नीति द्वारा निर्देशित 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