ઘણી બધી ફ્રી રેમ, NVMe Intel P4500 અને બધું અત્યંત ધીમું છે - સ્વેપ પાર્ટીશનના અસફળ ઉમેરણની વાર્તા

આ લેખમાં, હું એવી પરિસ્થિતિ વિશે વાત કરીશ કે જે તાજેતરમાં અમારા VPS ક્લાઉડમાંના એક સર્વર સાથે આવી હતી, જેણે મને ઘણા કલાકો સુધી સ્ટમ્પ કર્યા હતા. હું લગભગ 15 વર્ષથી લિનક્સ સર્વર્સને ગોઠવી અને મુશ્કેલીનિવારણ કરી રહ્યો છું, પરંતુ આ કેસ મારી પ્રેક્ટિસમાં બિલકુલ બંધબેસતો નથી - મેં ઘણી ખોટી ધારણાઓ કરી અને હું સમસ્યાનું કારણ યોગ્ય રીતે નક્કી કરી શક્યો અને તેને હલ કરી શક્યો તે પહેલાં હું થોડો ભયાવહ બન્યો. .

પ્રસ્તાવના

અમે મધ્યમ કદના ક્લાઉડનું સંચાલન કરીએ છીએ, જે અમે નીચેના રૂપરેખાંકન સાથે પ્રમાણભૂત સર્વર પર બનાવીએ છીએ - 32 કોરો, 256 GB RAM અને 4500TB PCI-E Intel P4 NVMe ડ્રાઇવ. અમને આ રૂપરેખાંકન ખરેખર ગમે છે કારણ કે તે VM ઇન્સ્ટન્સ પ્રકાર સ્તર પર યોગ્ય પ્રતિબંધ પ્રદાન કરીને IO ઓવરહેડ વિશે ચિંતા કરવાની જરૂરિયાતને દૂર કરે છે. કારણ કે NVMe ઇન્ટેલ P4500 પ્રભાવશાળી પ્રદર્શન ધરાવે છે, અમે એકસાથે મશીનો માટે સંપૂર્ણ IOPS જોગવાઈ અને બેકઅપ સ્ટોરેજ શૂન્ય IOWAIT સાથે બેકઅપ સર્વર પર પ્રદાન કરી શકીએ છીએ.

અમે એવા જૂના વિશ્વાસીઓમાંના એક છીએ કે જેઓ 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 જીબી/સેકંડની પ્રક્રિયા કરવા સક્ષમ નથી, જેને હાઇપરવાઇઝર હોસ્ટ સરળતાથી કરી શકે છે. ઉત્પાદન

આગળની વાર્તા માટે ઉપરોક્ત નકલ કરવાની પ્રક્રિયા ખૂબ જ મહત્વપૂર્ણ છે, જેમાં વિગતોનો સમાવેશ થાય છે - ઝડપી Intel 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 RAIDs સાથે સંખ્યાબંધ લેગસી નોડ્સ છે, તેમના માટે આ સંબંધિત છે, તેથી તેઓ આગળ વધી રહ્યા છે જેમ છે. એકંદરે, આ કોડનો માત્ર એક રસપ્રદ ભાગ છે જે નિરર્થકતાને સમજાવે છે ionice આવા રૂપરેખાંકનના કિસ્સામાં.

ધ્વજ પર ધ્યાન આપો iflag=direct માટે DD. વાંચતી વખતે IO બફરની બિનજરૂરી બદલીને ટાળવા માટે અમે બફર કેશને બાયપાસ કરીને ડાયરેક્ટ IO નો ઉપયોગ કરીએ છીએ. જો કે, oflag=direct અમે એટલા માટે નથી કારણ કે તેનો ઉપયોગ કરતી વખતે અમને ZFS પ્રદર્શન સમસ્યાઓનો સામનો કરવો પડ્યો છે.

અમે ઘણા વર્ષોથી આ યોજનાનો સફળતાપૂર્વક ઉપયોગ કરી રહ્યા છીએ.

અને પછી તે શરૂ થયું... અમે શોધી કાઢ્યું કે એક નોડનો હવે બેકઅપ લેવામાં આવ્યો નથી, અને પહેલાનો એક 50% ના ભયંકર IOWAIT સાથે ચાલી રહ્યો હતો. નકલ કેમ થતી નથી તે સમજવાનો પ્રયાસ કરતી વખતે, અમને નીચેની ઘટનાનો સામનો કરવો પડ્યો:

Volume group "images" not found

અમે "Intel P4500 નો અંત આવી ગયો છે" વિશે વિચારવાનું શરૂ કર્યું, જો કે, ડ્રાઇવને બદલવા માટે સર્વરને બંધ કરતા પહેલા, બેકઅપ લેવાનું હજુ પણ જરૂરી હતું. અમે LVM2 બેકઅપમાંથી મેટાડેટા પુનઃસ્થાપિત કરીને LVM2 ને ઠીક કર્યું છે:

vgcfgrestore images

અમે બેકઅપ લોંચ કર્યું અને આ ઓઇલ પેઇન્ટિંગ જોયું:

ફરીથી અમે ખૂબ જ ઉદાસી હતા - તે સ્પષ્ટ હતું કે અમે આ રીતે જીવી શકતા નથી, કારણ કે તમામ VPSs પીડાશે, જેનો અર્થ છે કે અમે પણ સહન કરીશું. શું થયું તે સંપૂર્ણપણે અસ્પષ્ટ છે - iostat દયનીય IOPS અને સૌથી વધુ IOWAIT દર્શાવ્યું. "ચાલો NVMe ને બદલીએ" સિવાયના કોઈ વિચારો નહોતા, પરંતુ સમયસર એક સમજ આવી.

પરિસ્થિતિનું તબક્કાવાર વિશ્લેષણ

ઐતિહાસિક મેગેઝિન. થોડા દિવસો પહેલા, આ સર્વર પર 128 જીબી રેમ સાથે વિશાળ 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