ብዙ ነፃ ራም ፣ NVMe Intel P4500 እና ሁሉም ነገር እጅግ በጣም ቀርፋፋ ነው - የስዋፕ ክፍልፍል ያልተሳካ የመደመር ታሪክ።

በዚህ ጽሑፍ ውስጥ, በ VPS ደመና ውስጥ ከአንዱ አገልጋይ ጋር በቅርቡ ስለተከሰተው ሁኔታ እናገራለሁ, ይህም ለብዙ ሰዓታት እንድደናቀፍ አድርጎኛል. ለ 15 ዓመታት ያህል የሊኑክስ አገልጋዮችን በማዋቀር እና በመፈለግ ላይ ቆይቻለሁ ፣ ግን ይህ ጉዳይ ከልምዴ ጋር አይጣጣምም - ብዙ የውሸት ግምቶችን አድርጌያለሁ እና የችግሩን መንስኤ በትክክል ለማወቅ እና መፍትሄ ከማግኘቴ በፊት ትንሽ ተስፋ ቆርጫለሁ። .

መግቢያ

መካከለኛ መጠን ያለው ደመናን እንሠራለን ፣ ይህም በሚከተለው ውቅር በመደበኛ አገልጋዮች ላይ እንገነባለን - 32 ኮሮች ፣ 256 ጂቢ RAM እና 4500TB PCI-E Intel P4 NVMe ድራይቭ። በ VM ምሳሌ አይነት ደረጃ ላይ ትክክለኛውን ገደብ በማቅረብ ስለ IO overhead መጨነቅን ስለሚያስወግድ ይህን ውቅር በጣም እንወዳለን። ምክንያቱም NVMe ኢንቴል P4500 አስደናቂ አፈጻጸም አለው፣ ሁለቱንም ሙሉ የIOPS አቅርቦት ለማሽኖች እና የመጠባበቂያ ማከማቻ ዜሮ IOWAIT ላለው የመጠባበቂያ አገልጋይ በአንድ ጊዜ ማቅረብ እንችላለን።

እኛ hyperconverged SDN እና ሌሎች ቄንጠኛ, ፋሽን, ወጣቶች ነገሮች VM ጥራዞች ለማከማቸት የማይጠቀሙ እነዚያ የድሮ አማኞች መካከል አንዱ ነን, ቀላል ሥርዓት, ቀላል ሁኔታዎች ውስጥ መላ መፈለግ እንደሆነ በማመን "ዋና ጉሩ ሄዷል" ሁኔታዎች. ወደ ተራሮች" በውጤቱም፣ የVM ጥራዞችን በQCOW2 ቅርጸት በXFS ወይም EXT4 ውስጥ እናከማቻለን፣ ይህም በ LVM2 ላይ ተዘርግቷል።

እንዲሁም ለኦርኬስትራ የምንጠቀመው ምርት QCOW2 ን ለመጠቀም እንገደዳለን - Apache CloudStack።

ምትኬን ለመስራት የድምፁን ሙሉ ምስል እንደ LVM2 ቅጽበታዊ ገጽ እይታ እንይዛለን (አዎ፣ የ LVM2 ቅጽበተ-ፎቶዎች ቀርፋፋ መሆናቸውን እናውቃለን፣ ግን Intel P4500 እዚህም ይረዳናል)። እናደርጋለን lvmcreate -s .. እና በእርዳታው dd የመጠባበቂያ ቅጂውን ZFS ማከማቻ ወዳለው የርቀት አገልጋይ እንልካለን። እዚህ እኛ አሁንም በትንሹ ተራማጅ ነን - ከሁሉም በላይ ፣ ZFS መረጃን በተጨመቀ መልክ ማከማቸት ይችላል ፣ እና እኛ በመጠቀም በፍጥነት ወደነበረበት መመለስ እንችላለን DD ወይም በመጠቀም የግለሰብ ቪኤም መጠኖችን ያግኙ mount -o loop ....

የ LVM2 ድምጽን ሙሉ ምስል ሳይሆን የፋይል ስርዓቱን በ ውስጥ መጫን ይችላሉ። RO እና የ QCOW2 ምስሎችን እራሳቸው ይገለብጡ, ሆኖም ግን, XFS ከዚህ መጥፎ የመሆኑ እውነታ አጋጥሞናል, እና ወዲያውኑ አይደለም, ነገር ግን በማይታወቅ መንገድ. የሃይፐርቫይዘር አስተናጋጆች በሳምንቱ መጨረሻ፣ በሌሊት ወይም በበዓል ቀን መቼ እንደሚሆኑ ግልጽ ባልሆኑ ስህተቶች በድንገት “ሲጣበቁ” አንወድም። ስለዚህ፣ ለXFS በቅጽበተ-ፎቶ መጫንን አንጠቀምም። RO መጠኖችን ለማውጣት በቀላሉ ሙሉውን የ LVM2 መጠን እንቀዳለን።

ወደ መጠባበቂያ አገልጋዩ የመጠባበቂያ ፍጥነት በእኛ ሁኔታ የሚወሰነው በመጠባበቂያ አገልጋዩ አፈጻጸም ሲሆን ይህም ከ600-800 ሜባ/ሰከንድ ለማይጨበጥ መረጃ ነው፤ ተጨማሪ ገደብ ደግሞ የመጠባበቂያ አገልጋዩ የተገናኘበት 10Gbit/s ቻናል ነው። ወደ ክላስተር.

በዚህ አጋጣሚ የ8 ሃይፐርቪዘር ሰርቨሮች መጠባበቂያ ቅጂዎች በአንድ ጊዜ ወደ አንድ መጠባበቂያ አገልጋይ ይሰቀላሉ። ስለዚህ የመጠባበቂያ አገልጋዩ የዲስክ እና የአውታረ መረብ ስርአቶች ቀርፋፋ ሲሆኑ የሃይፐርቫይዘር አስተናጋጆች የዲስክ ስርአቶች ከመጠን በላይ እንዲጫኑ አይፈቅዱም ምክንያቱም በቀላሉ 8 ጂቢ/ሰከንድ ማካሄድ ስለማይችሉ ሃይፐርቫይዘር አስተናጋጁ በቀላሉ ሊያስተናግደው ይችላል። ማምረት.

ከላይ ያለው የመቅዳት ሂደት ለቀጣይ ታሪክ በጣም አስፈላጊ ነው, ዝርዝሮችን ጨምሮ - ፈጣን ኢንቴል P4500 ድራይቭ በመጠቀም, NFS ን በመጠቀም እና ምናልባትም, ZFS ን በመጠቀም.

የመጠባበቂያ ታሪክ

በእያንዳንዱ የሃይፐርቫይዘር መስቀለኛ መንገድ ላይ 8 ጂቢ መጠን ያለው ትንሽ የ SWAP ክፍልፍል አለን እና የሃይፐርቫይዘር መስቀለኛ መንገድን ራሱ ተጠቅመን "እናወጣለን" DD ከማጣቀሻው ምስል. በሰርቨሮች ላይ ላለው የስርዓት መጠን 2xSATA SSD RAID1 ወይም 2xSAS HDD RAID1 በ LSI ወይም HP ሃርድዌር መቆጣጠሪያ ላይ እንጠቀማለን። በአጠቃላይ የስርዓታችን መጠን ከSWAP በስተቀር በ"ተነባቢ ብቻ" ሁነታ ስለሚሰራ በውስጣችን ስላለው ነገር ምንም ግድ የለንም። እና በአገልጋዩ ላይ ብዙ ራም ስላለን እና ከ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] 

ነገር ግን፣ ከተለመዱት የኤስኤስዲ RAIDዎች ጋር በርካታ የቆዩ ኖዶች አሉን ፣ ለእነሱ ይህ ጠቃሚ ነው ፣ ስለሆነም ይንቀሳቀሳሉ ባለበት. በአጠቃላይ ይህ ከንቱነትን የሚያብራራ አንድ አስደሳች ኮድ ነው። ionice እንደዚህ አይነት ውቅር ከሆነ.

ለባንዲራ ትኩረት ይስጡ iflag=direct ለ DD. በማንበብ ጊዜ አላስፈላጊ የ IO ቋቶችን ለመተካት የቋት መሸጎጫውን በማለፍ ቀጥታ IO እንጠቀማለን። ሆኖም፣ oflag=direct በምንጠቀምበት ጊዜ የZFS አፈጻጸም ችግሮች ስላጋጠሙን አይደለም::

ይህንን እቅድ ለብዙ አመታት ያለምንም ችግር በተሳካ ሁኔታ እየተጠቀምንበት ነበር.

ከዚያም ተጀመረ... አንደኛው መስቀለኛ መንገድ ከአሁን በኋላ መደገፊያ እንዳልነበረው ደርሰንበታል፣ እና ቀዳሚው 50% በሆነ አስፈሪ IOWAIT እየሄደ መሆኑን ደርሰንበታል። ለምን መቅዳት እንደማይከሰት ለመረዳት ስንሞክር የሚከተለውን ክስተት አጋጥሞናል፡

Volume group "images" not found

ስለ "መጨረሻው ለ Intel P4500 ደርሷል" ብለን ማሰብ ጀመርን, ነገር ግን ድራይቭን ለመተካት አገልጋዩን ከማጥፋትዎ በፊት, አሁንም ምትኬን ማከናወን አስፈላጊ ነበር. ከ LVM2 ምትኬ ሜታዳታን ወደነበረበት በመመለስ LVM2 አስተካክለናል፡

vgcfgrestore images

ምትኬ አስጀመርን እና ይህን የዘይት ሥዕል አየን፡-

በድጋሚ በጣም አዝነናል - ሁሉም ቪፒኤስዎች ስለሚሰቃዩ እኛ እንደዚህ መኖር እንደማንችል ግልጽ ነበር ይህም ማለት እኛ ደግሞ እንሰቃያለን ማለት ነው. የተከሰተው ነገር ሙሉ በሙሉ ግልጽ አይደለም - iostat አሳዛኝ IOPS እና ከፍተኛውን IOWAIT አሳይቷል። ከ"NVMeን እንተካ" ከማለት ውጪ ምንም ሃሳቦች አልነበሩም ነገር ግን ግንዛቤ በጊዜው ተከስቷል።

የሁኔታውን ደረጃ በደረጃ ትንተና

ታሪካዊ መጽሔት. ከጥቂት ቀናት በፊት, በዚህ አገልጋይ ላይ 128 ጂቢ RAM ያለው ትልቅ ቪፒኤስ መፍጠር አስፈላጊ ነበር. በቂ ማህደረ ትውስታ ያለ ቢመስልም በአስተማማኝ ጎን ለመሆን ሌላ 32 ጂቢ ለዋዋጭ ክፍልፍል መድበናል። VPS ተፈጠረ፣ ስራውን በተሳካ ሁኔታ አጠናቀቀ እና ክስተቱ ተረሳ፣ ነገር ግን የ SWAP ክፍልፍል ቀረ።

የማዋቀር ባህሪዎች. ለሁሉም የደመና አገልጋዮች መለኪያው vm.swappiness ወደ ነባሪ ተቀናብሯል። 60. እና SWAP የተፈጠረው በSAS HDD RAID1 ላይ ነው።

ምን ተፈጠረ (አዘጋጆቹ እንዳሉት). ምትኬ ሲቀመጥ DD ለኤንኤፍኤስ ከመጻፍዎ በፊት በ RAM ቋት ውስጥ የተቀመጠ ብዙ የጽሑፍ መረጃዎችን አዘጋጀ። የስርዓት ኮር፣ በፖሊሲ የሚመራ swappiness, ብዙ የVPS ማህደረ ትውስታ ገፆችን ወደ ስዋፕ ቦታ ያንቀሳቅስ ነበር፣ ይህም በቀስታ HDD RAID1 ድምጽ ላይ ወደነበረው። ይህ IOWAIT በጣም በጠንካራ ሁኔታ እንዲያድግ አደረገ፣ ነገር ግን በIO NVMe ምክንያት ሳይሆን በ IO HDD RAID1 ምክንያት።

ችግሩ እንዴት እንደተፈታ. የ32GB ስዋፕ ክፍልፍል ተሰናክሏል። ይህ 16 ሰአታት ፈጅቷል፤ SWAP እንዴት እና ለምን በዝግታ እንደሚጠፋ ለየብቻ ማንበብ ይችላሉ። ቅንብሮች ተለውጠዋል swappiness እኩል ወደሆነ እሴት 5 በሁሉም ደመና ላይ.

ይህ እንዴት ሊሆን አልቻለም?. በመጀመሪያ፣ SWAP በኤስኤስዲ RAID ወይም NVMe መሣሪያ ላይ ቢሆን፣ ሁለተኛ፣ ምንም NVMe መሣሪያ ከሌለ፣ ነገር ግን ቀርፋፋ መሣሪያ ይህን ያህል የውሂብ መጠን የማያወጣ ከሆነ - የሚገርመው፣ ችግሩ የተከሰተው NVMe በጣም ፈጣን ስለሆነ ነው።

ከዚያ በኋላ, ሁሉም ነገር እንደበፊቱ መስራት ጀመረ - ከዜሮ IOWAIT ጋር.

ምንጭ: hab.com