भरपूर मोफत RAM, NVMe Intel P4500 आणि सर्व काही अत्यंत संथ आहे - स्वॅप विभाजनाच्या अयशस्वी जोडणीची कहाणी

या लेखात, मी अलीकडेच आमच्या व्हीपीएस क्लाउडमधील एका सर्व्हरसह उद्भवलेल्या परिस्थितीबद्दल बोलेन, ज्याने मला कित्येक तास स्टंप केले. मी सुमारे 15 वर्षांपासून लिनक्स सर्व्हर कॉन्फिगर आणि समस्यानिवारण करत आहे, परंतु हे प्रकरण माझ्या सरावात अजिबात बसत नाही - मी समस्येचे कारण योग्यरित्या निर्धारित करण्यात आणि त्याचे निराकरण करण्यात सक्षम होण्याआधी मी अनेक चुकीच्या गृहीतके बांधली आणि थोडासा हताश झालो. .

प्रस्तावना

आम्ही मध्यम आकाराचे क्लाउड ऑपरेट करतो, जे आम्ही खालील कॉन्फिगरेशनसह मानक सर्व्हरवर तयार करतो - 32 कोर, 256 GB RAM आणि 4500TB PCI-E Intel P4 NVMe ड्राइव्ह. आम्हाला हे कॉन्फिगरेशन खरोखर आवडते कारण ते VM उदाहरण प्रकार स्तरावर योग्य प्रतिबंध प्रदान करून IO ओव्हरहेडबद्दल काळजी करण्याची गरज दूर करते. कारण NVMe इंटेल P4500 प्रभावी कामगिरी आहे, आम्ही एकाच वेळी मशीनला संपूर्ण IOPS तरतूद आणि शून्य IOWAIT असलेल्या बॅकअप सर्व्हरला बॅकअप स्टोरेज प्रदान करू शकतो.

आम्ही त्या जुन्या आस्तिकांपैकी एक आहोत जे हायपरकन्व्हर्ज्ड SDN आणि इतर स्टाईलिश, फॅशनेबल, तरुण गोष्टी VM व्हॉल्यूम संचयित करण्यासाठी वापरत नाहीत, असा विश्वास आहे की प्रणाली जितकी सोपी असेल तितके "मुख्य गुरु गेले" या परिस्थितीत समस्यानिवारण करणे सोपे आहे. डोंगरावर." परिणामी, आम्ही VM व्हॉल्यूम QCOW2 स्वरूपात XFS किंवा EXT4 मध्ये संग्रहित करतो, जे LVM2 च्या शीर्षस्थानी तैनात केले जाते.

आम्ही ऑर्केस्ट्रेशनसाठी वापरत असलेल्या उत्पादनाद्वारे देखील आम्हाला QCOW2 वापरण्यास भाग पाडले जाते - Apache CloudStack.

बॅकअप करण्यासाठी, आम्ही LVM2 स्नॅपशॉट म्हणून व्हॉल्यूमची संपूर्ण प्रतिमा घेतो (होय, आम्हाला माहित आहे की LVM2 स्नॅपशॉट्स धीमे आहेत, परंतु इंटेल 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/सेकंद प्रक्रिया करू शकत नाहीत, जे हायपरवाइजर होस्ट सहजपणे करू शकतात. उत्पादन

वरील कॉपी करण्याची प्रक्रिया तपशीलांसह पुढील कथेसाठी खूप महत्त्वाची आहे - वेगवान इंटेल P4500 ड्राइव्ह वापरणे, NFS वापरणे आणि बहुधा ZFS वापरणे.

बॅकअप कथा

प्रत्येक हायपरवाइजर नोडवर आमच्याकडे 8 GB आकाराचे एक लहान 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

आम्ही "Intel P4500 चा शेवट आला आहे" याबद्दल विचार करायला सुरुवात केली, तथापि, ड्राइव्ह पुनर्स्थित करण्यासाठी सर्व्हर बंद करण्यापूर्वी, बॅकअप घेणे अद्याप आवश्यक होते. आम्ही LVM2 बॅकअपमधून मेटाडेटा पुनर्संचयित करून LVM2 निश्चित केले:

vgcfgrestore images

आम्ही एक बॅकअप लॉन्च केला आणि हे तेल चित्र पाहिले:

पुन्हा आम्ही खूप दुःखी होतो - हे स्पष्ट होते की आम्ही असे जगू शकत नाही, कारण सर्व VPS ला त्रास होईल, याचा अर्थ आम्हालाही त्रास होईल. काय झाले ते पूर्णपणे अस्पष्ट आहे - iostat दयनीय IOPS आणि सर्वोच्च IOWAIT दाखवले. "चला NVMe रिप्लेस करू" याशिवाय इतर कोणतीही कल्पना नव्हती, परंतु वेळेत एक अंतर्दृष्टी आली.

टप्प्याटप्प्याने परिस्थितीचे विश्लेषण

ऐतिहासिक मासिक. काही दिवसांपूर्वी, या सर्व्हरवर 128 जीबी रॅमसह एक मोठा VPS तयार करणे आवश्यक होते. पुरेशी मेमरी आहे असे दिसते, परंतु सुरक्षित बाजूने, आम्ही स्वॅप विभाजनासाठी आणखी 32 GB वाटप केले. VPS तयार केले गेले, यशस्वीरित्या त्याचे कार्य पूर्ण केले आणि घटना विसरली गेली, परंतु SWAP विभाजन राहिले.

कॉन्फिगरेशन वैशिष्ट्ये. सर्व क्लाउड सर्व्हरसाठी पॅरामीटर vm.swappiness डीफॉल्टवर सेट केले होते 60. आणि SAS HDD RAID1 वर SWAP तयार केले गेले.

काय झाले (संपादकांच्या मते). बॅकअप घेत असताना DD भरपूर लेखन डेटा तयार केला, जो NFS ला लिहिण्यापूर्वी RAM बफरमध्ये ठेवला होता. सिस्टम कोर, धोरणाद्वारे मार्गदर्शित swappiness, स्लो HDD RAID1 व्हॉल्यूमवर असलेल्या VPS मेमरीची अनेक पृष्ठे स्वॅप क्षेत्रामध्ये हलवत होते. यामुळे IOWAIT ची जोरदार वाढ झाली, परंतु IO NVMe मुळे नाही तर IO HDD RAID1 मुळे.

समस्या कशी सुटली. 32GB स्वॅप विभाजन अक्षम केले होते. यास 16 तास लागले; SWAP इतक्या हळू कसे आणि का बंद होते याबद्दल तुम्ही स्वतंत्रपणे वाचू शकता. सेटिंग्ज बदलल्या आहेत swappiness च्या समान मूल्यापर्यंत 5 संपूर्ण ढगावर.

हे कसे घडले नाही?. प्रथम, जर SWAP SSD RAID किंवा NVMe डिव्हाइसवर असेल आणि दुसरे म्हणजे, NVMe डिव्हाइस नसल्यास, परंतु एक धीमे डिव्हाइस जे इतका डेटा तयार करणार नाही - गंमत म्हणजे, समस्या उद्भवली कारण ती NVMe खूप वेगवान आहे.

त्यानंतर, सर्व काही पूर्वीप्रमाणेच कार्य करू लागले - शून्य IOWAIT सह.

स्त्रोत: www.habr.com