చాలా ఉచిత RAM, NVMe ఇంటెల్ P4500 మరియు ప్రతిదీ చాలా నెమ్మదిగా ఉంది - స్వాప్ విభజన యొక్క విజయవంతం కాని జోడింపు కథ

ఈ వ్యాసంలో, ఇటీవల మా VPS క్లౌడ్ సర్వర్‌లలో ఒకదానితో ఎదురైన ఒక పరిస్థితిని వివరిస్తాను, అది నన్ను చాలా గంటల పాటు తికమక పెట్టింది. నేను సుమారు 15 సంవత్సరాలుగా సర్వర్‌లను కాన్ఫిగర్ చేస్తూ మరియు ట్రబుల్షూట్ చేస్తూ ఉన్నాను. Linuxకానీ, ఈ కేసు నా వృత్తికి అస్సలు సరిపోదు - సమస్యకు కారణాన్ని సరిగ్గా గుర్తించి, దాన్ని పరిష్కరించడానికి ముందు నేను అనేక తప్పుడు అంచనాలు వేసి, కాస్త నిరాశకు గురయ్యాను.

ప్రవేశిక

మేము మీడియం-సైజ్ క్లౌడ్‌ని ఆపరేట్ చేస్తాము, మేము ఈ క్రింది కాన్ఫిగరేషన్‌తో ప్రామాణిక సర్వర్‌లపై రూపొందించాము - 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 GB/సెకను నిర్వహించలేవు, హైపర్‌వైజర్ హోస్ట్‌లు దీన్ని సులభంగా నిర్వహించగలవు.

పైన పేర్కొన్న కాపీ ప్రక్రియ వివరాలతో సహా తదుపరి కథనం కోసం చాలా ముఖ్యమైనది - వేగవంతమైన 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 RAIDలతో అనేక లెగసీ నోడ్‌లను కలిగి ఉన్నాము, వాటికి ఇది సంబంధితంగా ఉంటుంది, కాబట్టి అవి కదులుతున్నాయి అలాగే. మొత్తంమీద, ఇది నిష్ఫలతను వివరించే ఒక ఆసక్తికరమైన కోడ్ భాగం ionice అటువంటి కాన్ఫిగరేషన్ విషయంలో.

జెండాపై శ్రద్ధ వహించండి iflag=direct కోసం DD. చదివేటప్పుడు IO బఫర్‌ల అనవసర రీప్లేస్‌మెంట్‌ను నివారించడానికి మేము బఫర్ కాష్‌ని బైపాస్ చేస్తూ డైరెక్ట్ IOని ఉపయోగిస్తాము. అయితే, oflag=direct ZFSని ఉపయోగిస్తున్నప్పుడు మేము పనితీరు సమస్యలను ఎదుర్కొన్నందున మేము అలా చేయము.

మేము ఈ పథకాన్ని అనేక సంవత్సరాలుగా సమస్యలు లేకుండా విజయవంతంగా ఉపయోగిస్తున్నాము.

ఆపై అది ప్రారంభమైంది... నోడ్‌లలో ఒకటి బ్యాకప్ చేయబడలేదని మరియు మునుపటిది 50% భయంకరమైన IOWAITతో నడుస్తోందని మేము కనుగొన్నాము. కాపీ చేయడం ఎందుకు జరగదని అర్థం చేసుకోవడానికి ప్రయత్నిస్తున్నప్పుడు, మేము ఈ క్రింది దృగ్విషయాన్ని ఎదుర్కొన్నాము:

Volume group "images" not found

మేము "ఇంటెల్ P4500 కోసం ముగింపు వచ్చింది" గురించి ఆలోచించడం ప్రారంభించాము, అయినప్పటికీ, డ్రైవ్‌ను భర్తీ చేయడానికి సర్వర్‌ను ఆపివేయడానికి ముందు, బ్యాకప్ చేయడం ఇప్పటికీ అవసరం. మేము LVM2 బ్యాకప్ నుండి మెటాడేటాను పునరుద్ధరించడం ద్వారా LVM2ని పరిష్కరించాము:

vgcfgrestore images

మేము బ్యాకప్‌ని ప్రారంభించాము మరియు ఈ ఆయిల్ పెయింటింగ్‌ని చూశాము:

మళ్ళీ మేము చాలా విచారంగా ఉన్నాము - మేము ఇలా జీవించలేమని స్పష్టమైంది, ఎందుకంటే అన్ని VPS లు బాధపడతాయి, అంటే మనం కూడా బాధపడతాము. ఏమి జరిగిందో పూర్తిగా అస్పష్టంగా ఉంది - iostat దయనీయమైన IOPS మరియు అత్యధిక IOWAITని చూపించింది. "NVMeని భర్తీ చేద్దాం" తప్ప మరే ఇతర ఆలోచనలు లేవు, కానీ ఒక అంతర్దృష్టి సమయానికి సంభవించింది.

దశల వారీగా పరిస్థితి యొక్క విశ్లేషణ

చారిత్రక పత్రిక. కొన్ని రోజుల ముందు, ఈ సర్వర్‌లో 128 GB RAMతో పెద్ద 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