అందరికి వందనాలు! నా పేరు డిమిత్రి సామ్సోనోవ్, నేను ఓడ్నోక్లాస్నికిలో ప్రముఖ సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా పని చేస్తున్నాను. మా క్లౌడ్‌లో 7 వేల కంటే ఎక్కువ ఫిజికల్ సర్వర్లు, 11 వేల కంటైనర్‌లు మరియు 200 అప్లికేషన్‌లు ఉన్నాయి, ఇవి వివిధ కాన్ఫిగరేషన్‌లలో 700 విభిన్న క్లస్టర్‌లను ఏర్పరుస్తాయి. అత్యధిక సర్వర్లు CentOS 7ని అమలు చేస్తాయి.
ఆగస్టు 14, 2018న, FragmentSmack దుర్బలత్వం గురించిన సమాచారం ప్రచురించబడింది
() మరియు సెగ్మెంట్స్మాక్ () ఇవి నెట్వర్క్ అటాక్ వెక్టర్ మరియు చాలా ఎక్కువ స్కోర్ (7.5)తో ఉన్న దుర్బలత్వాలు, ఇది రిసోర్స్ ఎగ్జాస్షన్ (CPU) కారణంగా సేవ తిరస్కరణ (DoS)ని బెదిరిస్తుంది. ఆ సమయంలో FragmentSmack కోసం కెర్నల్ పరిష్కారాన్ని ప్రతిపాదించలేదు; అంతేకాకుండా, దుర్బలత్వం గురించిన సమాచారాన్ని ప్రచురించడం కంటే ఇది చాలా ఆలస్యంగా బయటకు వచ్చింది. సెగ్మెంట్‌స్మాక్‌ను తొలగించడానికి, కెర్నల్‌ను అప్‌డేట్ చేయాలని సూచించబడింది. నవీకరణ ప్యాకేజీ అదే రోజున విడుదల చేయబడింది, దానిని ఇన్‌స్టాల్ చేయడం మాత్రమే మిగిలి ఉంది.
లేదు, మేము కెర్నల్‌ను అప్‌డేట్ చేయడానికి వ్యతిరేకం కాదు! అయితే, సూక్ష్మ నైపుణ్యాలు ఉన్నాయి ...
మేము ఉత్పత్తిపై కెర్నల్‌ను ఎలా అప్‌డేట్ చేస్తాము
సాధారణంగా, సంక్లిష్టంగా ఏమీ లేదు:
- ప్యాకేజీలను డౌన్‌లోడ్ చేయండి;
- వాటిని అనేక సర్వర్‌లలో ఇన్‌స్టాల్ చేయండి (మా క్లౌడ్‌ని హోస్ట్ చేసే సర్వర్‌లతో సహా);
- ఏమీ విరిగిపోలేదని నిర్ధారించుకోండి;
- అన్ని ప్రామాణిక కెర్నల్ సెట్టింగ్‌లు లోపాలు లేకుండా వర్తింపజేసినట్లు నిర్ధారించుకోండి;
- కొన్ని రోజులు వేచి ఉండండి;
- సర్వర్ పనితీరును తనిఖీ చేయండి;
- కొత్త సర్వర్‌ల విస్తరణను కొత్త కెర్నల్‌కు మార్చండి;
- డేటా సెంటర్ ద్వారా అన్ని సర్వర్‌లను నవీకరించండి (సమస్యల విషయంలో వినియోగదారులపై ప్రభావాన్ని తగ్గించడానికి ఒక సమయంలో ఒక డేటా సెంటర్);
- అన్ని సర్వర్‌లను రీబూట్ చేయండి.
మేము కలిగి ఉన్న కెర్నల్స్ యొక్క అన్ని శాఖల కోసం పునరావృతం చేయండి. ప్రస్తుతానికి ఇది:
- స్టాక్ CentOS 7 3.10 - చాలా సాధారణ సర్వర్‌ల కోసం;
- వనిల్లా 4.19 - మా కోసం , ఎందుకంటే మనకు BFQ, BBR, మొదలైనవి అవసరం;
- Elrepo కెర్నల్-ml 5.2 - కోసం , ఎందుకంటే 4.19 అస్థిరంగా ప్రవర్తిస్తుంది, కానీ అదే లక్షణాలు అవసరం.
మీరు ఊహించినట్లుగా, వేలాది సర్వర్‌లను రీబూట్ చేయడానికి ఎక్కువ సమయం పడుతుంది. అన్ని సర్వర్‌లకు అన్ని దుర్బలత్వాలు కీలకం కానందున, మేము ఇంటర్నెట్ నుండి నేరుగా యాక్సెస్ చేయగల వాటిని మాత్రమే రీబూట్ చేస్తాము. క్లౌడ్‌లో, వశ్యతను పరిమితం చేయకుండా ఉండటానికి, మేము కొత్త కెర్నల్‌తో వ్యక్తిగత సర్వర్‌లకు బాహ్యంగా యాక్సెస్ చేయగల కంటైనర్లను కట్టుకోము, కానీ మినహాయింపు లేకుండా అన్ని హోస్ట్‌లను రీబూట్ చేస్తాము. అదృష్టవశాత్తూ, సాధారణ సర్వర్‌ల కంటే అక్కడి విధానం సరళమైనది. ఉదాహరణకు, రీబూట్ సమయంలో స్థితిలేని కంటైనర్‌లు మరొక సర్వర్‌కు తరలించబడతాయి.
అయినప్పటికీ, ఇంకా చాలా పని ఉంది మరియు దీనికి చాలా వారాలు పట్టవచ్చు మరియు కొత్త సంస్కరణలో ఏవైనా సమస్యలు ఉంటే, చాలా నెలల వరకు. దాడి చేసేవారు దీన్ని బాగా అర్థం చేసుకుంటారు, కాబట్టి వారికి ప్లాన్ B అవసరం.
ఫ్రాగ్మెంట్స్మాక్/సెగ్మెంట్స్మాక్. ప్రత్యామ్నాయం
అదృష్టవశాత్తూ, కొన్ని దుర్బలత్వాల కోసం అటువంటి ప్లాన్ B ఉంది మరియు దీనిని వర్కరౌండ్ అంటారు. చాలా తరచుగా, ఇది కెర్నల్/అప్లికేషన్ సెట్టింగ్‌లలో మార్పు, ఇది సాధ్యమయ్యే ప్రభావాన్ని తగ్గించగలదు లేదా దుర్బలత్వాల దోపిడీని పూర్తిగా తొలగించగలదు.
FragmentSmack/SegmentSmack విషయంలో ఈ ప్రత్యామ్నాయం:
«మీరు net.ipv4.ipfrag_high_thresh మరియు net.ipv3.ipfrag_low_thresh (మరియు ipv4 net.ipv4.ipfrag_high_thresh మరియు net.ipv6.ipfrag_low_thresh మరియు net.ipv6.ipfrag_low_thresh మరియు net.ipv6.ipfrag_low_thresh కోసం వాటి ప్రతిరూపాలు) మరియు 256 kB లేదా వరుసగా kBBకి మీరు 192MB మరియు 262144MB డిఫాల్ట్ విలువలను మార్చవచ్చు. తక్కువ. హార్డ్‌వేర్, సెట్టింగ్‌లు మరియు షరతులపై ఆధారపడి దాడి సమయంలో CPU వినియోగంలో చిన్న నుండి గణనీయమైన తగ్గుదలని పరీక్షలు చూపుతాయి. అయితే, ipfrag_high_thresh=64 బైట్ల కారణంగా కొంత పనితీరు ప్రభావం ఉండవచ్చు, ఎందుకంటే ఒకేసారి రెండు XNUMXK శకలాలు మాత్రమే మళ్లీ అసెంబ్లీ క్యూలో సరిపోతాయి. ఉదాహరణకు, పెద్ద UDP ప్యాకెట్‌లతో పనిచేసే అప్లికేషన్‌లు విచ్ఛిన్నమయ్యే ప్రమాదం ఉంది".
పారామితులు స్వయంగా ఈ క్రింది విధంగా వివరించబడింది:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
ఉత్పత్తి సేవలపై మాకు పెద్ద UDPలు లేవు. LANలో ఫ్రాగ్మెంటెడ్ ట్రాఫిక్ లేదు; WANలో ఫ్రాగ్మెంటెడ్ ట్రాఫిక్ ఉంది, కానీ ముఖ్యమైనది కాదు. ఎటువంటి సంకేతాలు లేవు - మీరు పరిష్కారాన్ని రూపొందించవచ్చు!
ఫ్రాగ్మెంట్స్మాక్/సెగ్మెంట్స్మాక్. మొదటి రక్తం
మేము ఎదుర్కొన్న మొదటి సమస్య ఏమిటంటే, క్లౌడ్ కంటైనర్‌లు కొన్నిసార్లు కొత్త సెట్టింగ్‌లను పాక్షికంగా మాత్రమే (ipfrag_low_thresh) వర్తింపజేస్తాయి మరియు కొన్నిసార్లు వాటిని అస్సలు వర్తించవు - అవి ప్రారంభంలోనే క్రాష్ అయ్యాయి. సమస్యను స్థిరంగా పునరుత్పత్తి చేయడం సాధ్యం కాదు (అన్ని సెట్టింగ్‌లు ఎటువంటి ఇబ్బందులు లేకుండా మానవీయంగా వర్తింపజేయబడ్డాయి). కంటైనర్ ప్రారంభంలో ఎందుకు క్రాష్ అవుతుందో అర్థం చేసుకోవడం కూడా అంత సులభం కాదు: లోపాలు ఏవీ కనుగొనబడలేదు. ఒక విషయం ఖచ్చితంగా ఉంది: సెట్టింగ్‌లను వెనక్కి తిప్పడం కంటైనర్ క్రాష్‌లతో సమస్యను పరిష్కరిస్తుంది.
హోస్ట్‌లో Sysctlని వర్తింపజేయడం ఎందుకు సరిపోదు? కంటైనర్ దాని స్వంత ప్రత్యేక నెట్వర్క్ నేమ్‌స్పేస్‌లో నివసిస్తుంది, కాబట్టి కనీసం కంటైనర్‌లో హోస్ట్ నుండి భిన్నంగా ఉండవచ్చు.
కంటైనర్‌లో Sysctl సెట్టింగ్‌లు సరిగ్గా ఎలా వర్తింపజేయబడతాయి? మా కంటైనర్‌లు ప్రత్యేకించబడవు కాబట్టి, మీరు కంటైనర్‌లోకి వెళ్లడం ద్వారా ఏ Sysctl సెట్టింగ్‌ను మార్చలేరు - మీకు తగినంత హక్కులు లేవు. కంటైనర్లను అమలు చేయడానికి, ఆ సమయంలో మా క్లౌడ్ డాకర్‌ను ఉపయోగించింది (ఇప్పుడు ) కొత్త కంటైనర్ యొక్క పారామితులు అవసరమైన Sysctl సెట్టింగ్‌లతో సహా API ద్వారా డాకర్‌కు పంపబడ్డాయి.
సంస్కరణల ద్వారా శోధిస్తున్నప్పుడు, డాకర్ API అన్ని లోపాలను అందించలేదని తేలింది (కనీసం వెర్షన్ 1.10లో). మేము “డాకర్ రన్” ద్వారా కంటైనర్‌ను ప్రారంభించడానికి ప్రయత్నించినప్పుడు, మేము చివరకు కనీసం ఏదైనా చూసాము:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
పరామితి విలువ చెల్లదు. కానీ ఎందుకు? మరియు అది కొన్నిసార్లు మాత్రమే ఎందుకు చెల్లదు? Sysctl పారామీటర్‌లు వర్తించే క్రమంలో డాకర్ హామీ ఇవ్వదని తేలింది (తాజాగా పరీక్షించబడిన సంస్కరణ 1.13.1), కాబట్టి కొన్నిసార్లు ipfrag_low_thresh 256Mగా ఉన్నప్పుడు ipfrag_high_thresh 3Kకి సెట్ చేయడానికి ప్రయత్నించింది, అంటే, ఎగువ పరిమితి తక్కువగా ఉంటుంది. లోపానికి దారితీసిన తక్కువ పరిమితి కంటే.
ఆ సమయంలో, మేము ఇప్పటికే కంటైనర్‌ను ప్రారంభించిన తర్వాత (కంటైనర్‌ను స్తంభింపజేయడం) రీకాన్ఫిగర్ చేయడానికి మా స్వంత యంత్రాంగాన్ని ఉపయోగించాము. మరియు ద్వారా కంటైనర్ యొక్క నేమ్‌స్పేస్‌లో ఆదేశాలను అమలు చేయడం ), మరియు మేము ఈ భాగానికి Sysctl పారామితులను వ్రాయడం కూడా జోడించాము. సమస్య పరిష్కారమైంది.
ఫ్రాగ్మెంట్స్మాక్/సెగ్మెంట్స్మాక్. మొదటి రక్తం 2
క్లౌడ్‌లో వర్క్‌రౌండ్ వినియోగాన్ని అర్థం చేసుకోవడానికి మాకు సమయం లభించకముందే, వినియోగదారుల నుండి మొదటి అరుదైన ఫిర్యాదులు రావడం ప్రారంభించాయి. ఆ సమయంలో, మొదటి సర్వర్‌లలో వర్క్‌అరౌండ్‌ని ఉపయోగించడం ప్రారంభించి చాలా వారాలు గడిచాయి. వ్యక్తిగత సేవలపై ఫిర్యాదులు అందాయని, ఈ సేవలకు సంబంధించిన అన్ని సర్వర్లు కాదని ప్రాథమిక విచారణలో తేలింది. సమస్య మళ్లీ చాలా అనిశ్చితంగా మారింది.
అన్నింటిలో మొదటిది, మేము Sysctl సెట్టింగులను వెనక్కి తీసుకోవడానికి ప్రయత్నించాము, కానీ ఇది ఎటువంటి ప్రభావాన్ని చూపలేదు. సర్వర్ మరియు అప్లికేషన్ సెట్టింగ్‌లతో వివిధ అవకతవకలు కూడా సహాయపడలేదు. రీబూట్ సహాయపడింది. లైనక్స్‌ని రీబూట్ చేయడం పాత రోజుల్లో విండోస్‌కు సాధారణమైనట్లే అసహజమైనది. అయినప్పటికీ, ఇది సహాయపడింది మరియు Sysctlలో కొత్త సెట్టింగ్‌లను వర్తింపజేసేటప్పుడు మేము దానిని "కెర్నల్ గ్లిచ్" వరకు ఉంచాము. అది ఎంత పనికిమాలిన పని...
మూడు వారాల తర్వాత సమస్య పునరావృతమైంది. ఈ సర్వర్‌ల కాన్ఫిగరేషన్ చాలా సులభం: ప్రాక్సీ/బ్యాలన్సర్ మోడ్‌లో Nginx. పెద్దగా రద్దీ లేదు. కొత్త పరిచయ గమనిక: క్లయింట్‌లపై 504 ఎర్రర్‌ల సంఖ్య ప్రతిరోజూ పెరుగుతోంది () ఈ సేవ కోసం రోజుకు 504 ఎర్రర్‌ల సంఖ్యను గ్రాఫ్ చూపుతుంది:
అన్ని లోపాలు ఒకే బ్యాకెండ్ గురించి ఉన్నాయి - క్లౌడ్‌లో ఉన్న దాని గురించి. ఈ బ్యాకెండ్‌లోని ప్యాకేజీ శకలాల కోసం మెమరీ వినియోగ గ్రాఫ్ ఇలా ఉంది:
ఆపరేటింగ్ సిస్టమ్ గ్రాఫ్‌లలో సమస్య యొక్క అత్యంత స్పష్టమైన వ్యక్తీకరణలలో ఇది ఒకటి. క్లౌడ్‌లో, అదే సమయంలో, QoS (ట్రాఫిక్ కంట్రోల్) సెట్టింగ్‌లతో మరొక నెట్వర్క్ సమస్య పరిష్కరించబడింది. ప్యాకెట్ శకలాల కోసం మెమరీ వినియోగం యొక్క గ్రాఫ్‌లో, ఇది సరిగ్గా అదే విధంగా ఉంది:
ఊహ చాలా సులభం: గ్రాఫ్‌లలో అవి ఒకేలా కనిపిస్తే, వాటికి ఒకే కారణం ఉంటుంది. అంతేకాకుండా, ఈ రకమైన మెమరీతో ఏవైనా సమస్యలు చాలా అరుదు.
స్థిర సమస్య యొక్క సారాంశం ఏమిటంటే, మేము QoSలో డిఫాల్ట్ సెట్టింగ్‌లతో fq ప్యాకెట్ షెడ్యూలర్‌ని ఉపయోగించాము. డిఫాల్ట్‌గా, ఒక కనెక్షన్ కోసం, ఇది 100 ప్యాకెట్‌లను క్యూకి జోడించడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు కొన్ని కనెక్షన్‌లు, ఛానల్ కొరత ఉన్న పరిస్థితుల్లో, క్యూను సామర్థ్యానికి అడ్డుకోవడం ప్రారంభించాయి. ఈ సందర్భంలో, ప్యాకెట్లు పడిపోయాయి. tc గణాంకాలలో (tc -s qdisc) దీనిని ఇలా చూడవచ్చు:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
“464545 flows_plimit” అనేది ఒక కనెక్షన్ యొక్క క్యూ పరిమితిని అధిగమించడం వలన పడిపోయిన ప్యాకెట్లు మరియు “డ్రాప్డ్ 464545” అనేది ఈ షెడ్యూలర్ యొక్క అన్ని డ్రాప్ చేయబడిన ప్యాకెట్ల మొత్తం. క్యూ పొడవును 1 వేలకు పెంచి, కంటైనర్లను రీస్టార్ట్ చేసిన తర్వాత, సమస్య ఏర్పడటం ఆగిపోయింది. మీరు తిరిగి కూర్చుని స్మూతీ తాగవచ్చు.
ఫ్రాగ్మెంట్స్మాక్/సెగ్మెంట్స్మాక్. చివరి రక్తం
ముందుగా, కెర్నల్‌లోని దుర్బలత్వాలను ప్రకటించిన చాలా నెలల తర్వాత, FragmentSmack కోసం ఒక పరిష్కారం చివరకు కనిపించింది (ఆగస్టులో ప్రకటనతో పాటు, సెగ్మెంట్‌స్మాక్‌కు మాత్రమే పరిష్కారం విడుదల చేయబడిందని నేను మీకు గుర్తు చేస్తాను), ఇది మాకు వర్కరౌండ్‌ను విడిచిపెట్టడానికి అవకాశం ఇచ్చింది, ఇది మాకు చాలా ఇబ్బంది కలిగించింది. ఈ సమయంలో, మేము ఇప్పటికే కొన్ని సర్వర్‌లను కొత్త కెర్నల్‌కు బదిలీ చేయగలిగాము మరియు ఇప్పుడు మేము మొదటి నుండి ప్రారంభించవలసి వచ్చింది. FragmentSmack పరిష్కారానికి వేచి ఉండకుండా మేము కెర్నల్‌ను ఎందుకు అప్‌డేట్ చేసాము? వాస్తవం ఏమిటంటే, ఈ దుర్బలత్వాల నుండి రక్షించే ప్రక్రియ సెంటొస్‌ను నవీకరించే ప్రక్రియతో సమానంగా ఉంటుంది (మరియు విలీనం చేయబడింది) (దీనికి కెర్నల్‌ను మాత్రమే నవీకరించడం కంటే ఎక్కువ సమయం పడుతుంది). అదనంగా, SegmentSmack మరింత ప్రమాదకరమైన దుర్బలత్వం, మరియు దాని కోసం ఒక పరిష్కారం వెంటనే కనిపించింది, కాబట్టి ఇది ఏమైనప్పటికీ అర్ధవంతంగా ఉంటుంది. అయినప్పటికీ, CentOS 7.5 సమయంలో కనిపించిన FragmentSmack దుర్బలత్వం వెర్షన్ 7.6లో మాత్రమే పరిష్కరించబడింది, కాబట్టి మేము CentOSలో కెర్నల్‌ను అప్‌డేట్ చేయలేకపోయాము, కాబట్టి మేము అప్‌డేట్‌ను 7.5కి ఆపివేసి, 7.6కి అప్‌డేట్‌తో మళ్లీ ప్రారంభించాల్సి వచ్చింది. మరియు ఇది కూడా జరుగుతుంది.
రెండవది, సమస్యల గురించి అరుదైన వినియోగదారు ఫిర్యాదులు మాకు తిరిగి వచ్చాయి. అవన్నీ క్లయింట్‌ల నుండి మా సర్వర్‌లలో కొన్నింటికి ఫైల్‌ల అప్‌లోడ్‌కు సంబంధించినవని ఇప్పుడు మాకు ఇప్పటికే ఖచ్చితంగా తెలుసు. అంతేకాకుండా, మొత్తం మాస్ నుండి చాలా తక్కువ సంఖ్యలో అప్‌లోడ్‌లు ఈ సర్వర్‌ల ద్వారా జరిగాయి.
పై కథనం నుండి మనకు గుర్తున్నట్లుగా, Sysctlని వెనక్కి తీసుకురావడం సహాయం చేయలేదు. రీబూట్ సహాయపడింది, కానీ తాత్కాలికంగా.
Sysctlకు సంబంధించిన అనుమానాలు తొలగించబడలేదు, అయితే ఈసారి వీలైనంత ఎక్కువ సమాచారాన్ని సేకరించడం అవసరం. ఏమి జరుగుతుందో మరింత ఖచ్చితంగా అధ్యయనం చేయడానికి క్లయింట్‌లో అప్‌లోడ్ సమస్యను పునరుత్పత్తి చేసే సామర్థ్యం కూడా పెద్దగా లేకపోవడం.
అందుబాటులో ఉన్న అన్ని గణాంకాలు మరియు లాగ్‌ల విశ్లేషణ ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి మాకు మరింత దగ్గరగా తీసుకురాలేదు. నిర్దిష్ట కనెక్షన్‌ని "అనుభూతి" చేయడానికి సమస్యను పునరుత్పత్తి చేసే సామర్థ్యం తీవ్రంగా లేకపోవడం. చివరగా, డెవలపర్లు, అప్లికేషన్ యొక్క ప్రత్యేక సంస్కరణను ఉపయోగించి, Wi-Fi ద్వారా కనెక్ట్ చేయబడినప్పుడు పరీక్ష పరికరంలో సమస్యల స్థిరమైన పునరుత్పత్తిని సాధించగలిగారు. దీంతో విచారణలో ముందడుగు పడింది. క్లయింట్ Nginxకి కనెక్ట్ చేయబడింది, ఇది మా జావా అప్లికేషన్ అయిన బ్యాకెండ్‌కు ప్రాక్సీ చేయబడింది.
సమస్యల కోసం డైలాగ్ ఇలా ఉంది (Nginx ప్రాక్సీ వైపున పరిష్కరించబడింది):
- క్లయింట్: ఫైల్‌ను డౌన్‌లోడ్ చేయడం గురించి సమాచారాన్ని స్వీకరించడానికి అభ్యర్థన.
- జావా సర్వర్: ప్రతిస్పందన.
- క్లయింట్: ఫైల్‌తో పోస్ట్ చేయండి.
- జావా సర్వర్: లోపం.
అదే సమయంలో, జావా సర్వర్ క్లయింట్ నుండి 0 బైట్ల డేటా స్వీకరించబడిందని లాగ్‌కు వ్రాస్తుంది మరియు అభ్యర్థనకు 30 సెకన్ల కంటే ఎక్కువ సమయం పట్టిందని Nginx ప్రాక్సీ వ్రాస్తుంది (30 సెకన్లు క్లయింట్ అప్లికేషన్ యొక్క సమయం ముగిసింది). ఎందుకు గడువు ముగిసింది మరియు ఎందుకు 0 బైట్‌లు? HTTP దృక్కోణం నుండి, ప్రతిదీ తప్పక పని చేస్తుంది, కానీ ఫైల్‌తో POST నెట్వర్క్ నుండి కనిపించకుండా పోతుంది. అంతేకాకుండా, ఇది క్లయింట్ మరియు Nginx మధ్య అదృశ్యమవుతుంది. Tcpdumpతో మిమ్మల్ని మీరు ఆయుధం చేసుకునే సమయం ఇది! కానీ ముందుగా మీరు నెట్వర్క్ కాన్ఫిగరేషన్ను అర్థం చేసుకోవాలి. Nginx ప్రాక్సీ L3 బాలన్సర్ వెనుక ఉంది . టన్నెలింగ్ అనేది L3 బాలన్సర్ నుండి సర్వర్‌కు ప్యాకెట్‌లను బట్వాడా చేయడానికి ఉపయోగించబడుతుంది, ఇది ప్యాకెట్‌లకు దాని హెడర్‌లను జోడిస్తుంది:
ఈ సందర్భంలో, నెట్వర్క్ ఈ సర్వర్‌కి Vlan-ట్యాగ్ చేయబడిన ట్రాఫిక్ రూపంలో వస్తుంది, ఇది ప్యాకెట్‌లకు దాని స్వంత ఫీల్డ్‌లను కూడా జోడిస్తుంది:
మరియు ఈ ట్రాఫిక్ కూడా విభజించబడవచ్చు (వర్కౌరౌండ్ నుండి వచ్చే నష్టాలను అంచనా వేసేటప్పుడు మేము మాట్లాడిన ఇన్‌కమింగ్ ఫ్రాగ్మెంటెడ్ ట్రాఫిక్‌లో అదే చిన్న శాతం), ఇది హెడర్‌ల కంటెంట్‌ను కూడా మారుస్తుంది:
మరోసారి: ప్యాకెట్లు Vlan ట్యాగ్‌తో కప్పబడి ఉంటాయి, సొరంగంతో కప్పబడి ఉంటాయి, విభజించబడ్డాయి. ఇది ఎలా జరుగుతుందో బాగా అర్థం చేసుకోవడానికి, క్లయింట్ నుండి Nginx ప్రాక్సీకి ప్యాకెట్ మార్గాన్ని కనుగొనండి.
- ప్యాకెట్ L3 బ్యాలెన్సర్‌కు చేరుకుంటుంది. డేటా సెంటర్‌లో సరైన రూటింగ్ కోసం, ప్యాకెట్ సొరంగంలో కప్పబడి నెట్వర్క్ కార్డ్‌కి పంపబడుతుంది.
- ప్యాకెట్ + టన్నెల్ హెడర్‌లు MTUకి సరిపోవు కాబట్టి, ప్యాకెట్ ముక్కలుగా కట్ చేసి నెట్‌వర్క్‌కి పంపబడుతుంది.
- L3 బ్యాలెన్సర్ తర్వాత స్విచ్, ప్యాకెట్‌ను స్వీకరించినప్పుడు, దానికి Vlan ట్యాగ్‌ని జోడించి, దానిని ఆన్ చేస్తుంది.
- Nginx ప్రాక్సీ ముందు ఉన్న స్విచ్ (పోర్ట్ సెట్టింగ్‌ల ఆధారంగా) సర్వర్ Vlan-ఎన్‌క్యాప్సులేటెడ్ ప్యాకెట్‌ను ఆశిస్తున్నట్లు చూస్తుంది, కనుక ఇది Vlan ట్యాగ్‌ను తీసివేయకుండానే పంపుతుంది.
- Linux వ్యక్తిగత ప్యాకేజీల శకలాలను తీసుకుంటుంది మరియు వాటిని ఒక పెద్ద ప్యాకేజీగా విలీనం చేస్తుంది.
- తరువాత, ప్యాకెట్ Vlan ఇంటర్‌ఫేస్‌కు చేరుకుంటుంది, ఇక్కడ మొదటి పొర దాని నుండి తీసివేయబడుతుంది - Vlan ఎన్‌క్యాప్సులేషన్.
- Linux దానిని టన్నెల్ ఇంటర్‌ఫేస్‌కు పంపుతుంది, దాని నుండి మరొక పొర తీసివేయబడుతుంది - టన్నెల్ ఎన్‌క్యాప్సులేషన్.
ఇవన్నీ tcpdumpకి పారామీటర్‌లుగా పాస్ చేయడం కష్టం.
ముగింపు నుండి ప్రారంభిద్దాం: క్లయింట్‌ల నుండి vlan మరియు టన్నెల్ ఎన్‌క్యాప్సులేషన్ తీసివేయబడి క్లీన్ (అనవసరమైన శీర్షికలు లేకుండా) IP ప్యాకెట్లు ఉన్నాయా?
tcpdump host <ip клиента>
లేదు, సర్వర్‌లో అలాంటి ప్యాకేజీలు లేవు. కాబట్టి సమస్య ముందుగానే ఉండాలి. Vlan ఎన్‌క్యాప్సులేషన్ మాత్రమే తీసివేయబడిన ప్యాకెట్లు ఏమైనా ఉన్నాయా?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx అనేది హెక్స్ ఆకృతిలో క్లయింట్ IP చిరునామా.
32:4 — టన్నెల్ ప్యాకెట్‌లో SCR IP వ్రాయబడిన ఫీల్డ్ యొక్క చిరునామా మరియు పొడవు.
ఫీల్డ్ చిరునామాను బ్రూట్ ఫోర్స్ ద్వారా ఎంచుకోవలసి వచ్చింది, ఎందుకంటే ఇంటర్నెట్‌లో వారు 40, 44, 50, 54 గురించి వ్రాస్తారు, కానీ అక్కడ IP చిరునామా లేదు. మీరు హెక్స్‌లోని ప్యాకెట్‌లలో ఒకదానిని కూడా చూడవచ్చు (tcpdumpలోని -xx లేదా -XX పరామితి) మరియు మీకు తెలిసిన IP చిరునామాను లెక్కించవచ్చు.
Vlan మరియు టన్నెల్ ఎన్‌క్యాప్సులేషన్ తీసివేయబడని ప్యాకెట్ శకలాలు ఉన్నాయా?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
ఈ మేజిక్ చివరిదితో సహా అన్ని శకలాలు మనకు చూపుతుంది. బహుశా, అదే విషయం IP ద్వారా ఫిల్టర్ చేయబడవచ్చు, కానీ నేను ప్రయత్నించలేదు, ఎందుకంటే అలాంటి ప్యాకెట్లు చాలా లేవు మరియు నాకు అవసరమైనవి సాధారణ ప్రవాహంలో సులభంగా కనుగొనబడ్డాయి. వారు ఇక్కడ ఉన్నారు:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
ఇవి ఫోటోగ్రాఫ్‌తో ఒక ప్యాకేజీ (అదే ID 53652) యొక్క రెండు శకలాలు (మొదటి ప్యాకేజీలో Exif అనే పదం కనిపిస్తుంది). ఈ స్థాయిలో ప్యాకేజీలు ఉన్నా, డంపుల్లో విలీన రూపంలో కానందున, అసెంబ్లీలో సమస్య స్పష్టంగా ఉంది. చివరగా దీనికి డాక్యుమెంటరీ సాక్ష్యం ఉంది!
ప్యాకెట్ డీకోడర్ నిర్మాణాన్ని నిరోధించే ఏ సమస్యలను వెల్లడించలేదు. ఇక్కడ ప్రయత్నించారు: . మొదట, మీరు అక్కడ ఏదైనా నింపడానికి ప్రయత్నించినప్పుడు, డీకోడర్ ప్యాకెట్ ఆకృతిని ఇష్టపడదు. Srcmac మరియు Ethertype (ఫ్రాగ్మెంట్ సమాచారానికి సంబంధించినది కాదు) మధ్య కొన్ని అదనపు రెండు ఆక్టెట్‌లు ఉన్నాయని తేలింది. వాటిని తీసివేసిన తర్వాత, డీకోడర్ పని చేయడం ప్రారంభించింది. అయితే, ఇది ఎటువంటి సమస్యలను చూపించలేదు.
ఎవరెన్ని చెప్పినా ఆ Sysctl తప్ప మరేమీ దొరకలేదు. స్కేల్‌ను అర్థం చేసుకోవడానికి మరియు తదుపరి చర్యలపై నిర్ణయం తీసుకోవడానికి సమస్య సర్వర్‌లను గుర్తించడానికి ఒక మార్గాన్ని కనుగొనడం మాత్రమే మిగిలి ఉంది. అవసరమైన కౌంటర్ త్వరగా కనుగొనబడింది:
netstat -s | grep "packet reassembles failed”
ఇది OID=1.3.6.1.2.1.4.31.1.1.16.1 కింద snmpdలో కూడా ఉంది ().
"IP రీ-అసెంబ్లీ అల్గోరిథం ద్వారా కనుగొనబడిన వైఫల్యాల సంఖ్య (ఏదైనా కారణం: సమయం ముగిసింది, లోపాలు మొదలైనవి)."
సమస్యను అధ్యయనం చేసిన సర్వర్‌ల సమూహంలో, ఈ కౌంటర్ రెండింటిలో వేగంగా పెరిగింది, రెండు మరింత నెమ్మదిగా మరియు మరో రెండింటిలో ఇది అస్సలు పెరగలేదు. ఈ కౌంటర్ యొక్క డైనమిక్స్‌ను జావా సర్వర్‌లోని HTTP ఎర్రర్‌ల డైనమిక్స్‌తో పోల్చడం ఒక సహసంబంధాన్ని వెల్లడించింది. అంటే, మీటర్‌ను పర్యవేక్షించవచ్చు.
సమస్యల యొక్క నమ్మకమైన సూచికను కలిగి ఉండటం చాలా ముఖ్యం, తద్వారా Sysctlని రోలింగ్ బ్యాక్ చేయడం సహాయపడుతుందో లేదో మీరు ఖచ్చితంగా నిర్ణయించవచ్చు, ఎందుకంటే మునుపటి కథనం నుండి ఇది అప్లికేషన్ నుండి వెంటనే అర్థం చేసుకోబడదని మాకు తెలుసు. వినియోగదారులు దానిని కనుగొనే ముందు ఉత్పత్తిలో అన్ని సమస్యాత్మక ప్రాంతాలను గుర్తించడానికి ఈ సూచిక మమ్మల్ని అనుమతిస్తుంది.
Sysctlని వెనక్కి తీసుకున్న తర్వాత, పర్యవేక్షణ లోపాలు ఆగిపోయాయి, తద్వారా సమస్యలకు కారణం నిరూపించబడింది, అలాగే రోల్‌బ్యాక్ సహాయపడుతుంది.
మేము ఇతర సర్వర్‌లలో ఫ్రాగ్మెంటేషన్ సెట్టింగ్‌లను వెనక్కి తీసుకున్నాము, ఇక్కడ కొత్త పర్యవేక్షణ అమలులోకి వచ్చింది మరియు ఎక్కడో మేము డిఫాల్ట్ కంటే ఎక్కువ మెమరీని శకలాల కోసం కేటాయించాము (ఇది UDP గణాంకాలు, పాక్షిక నష్టం సాధారణ నేపథ్యంలో గుర్తించబడదు) .
అతి ముఖ్యమైన ప్రశ్నలు
మా L3 బ్యాలెన్సర్‌లో ప్యాకెట్లు ఎందుకు విభజించబడ్డాయి? వినియోగదారుల నుండి బ్యాలెన్సర్‌లకు వచ్చే చాలా ప్యాకెట్లు SYN మరియు ACK. ఈ ప్యాకేజీల పరిమాణాలు చిన్నవి. కానీ అటువంటి ప్యాకెట్ల వాటా చాలా పెద్దది కాబట్టి, వాటి నేపథ్యానికి వ్యతిరేకంగా, ముక్కలుగా మారడం ప్రారంభించిన పెద్ద ప్యాకెట్ల ఉనికిని మేము గమనించలేదు.
కారణం విరిగిన కాన్ఫిగరేషన్ స్క్రిప్ట్ Vlan ఇంటర్‌ఫేస్‌లతో సర్వర్‌లపై (ఆ సమయంలో ఉత్పత్తిలో ట్యాగ్ చేయబడిన ట్రాఫిక్‌తో చాలా తక్కువ సర్వర్లు ఉన్నాయి). మా దిశలో ప్యాకెట్లు పరిమాణంలో చిన్నవిగా ఉండాలనే సమాచారాన్ని క్లయింట్‌కు తెలియజేయడానికి Advmss అనుమతిస్తుంది, తద్వారా వాటికి సొరంగం శీర్షికలను జోడించిన తర్వాత వాటిని విచ్ఛిన్నం చేయవలసిన అవసరం లేదు.
Sysctl రోల్‌బ్యాక్ ఎందుకు సహాయం చేయలేదు, కానీ రీబూట్ చేసింది? రోలింగ్ బ్యాక్ Sysctl ప్యాకేజీలను విలీనం చేయడానికి అందుబాటులో ఉన్న మెమరీ మొత్తాన్ని మార్చింది. అదే సమయంలో, శకలాలు కోసం మెమరీ ఓవర్‌ఫ్లో చాలా వాస్తవం కనెక్షన్ల మందగమనానికి దారితీసింది, ఇది శకలాలు క్యూలో చాలా కాలం పాటు ఆలస్యం కావడానికి దారితీసింది. అంటే, ప్రక్రియ చక్రాలలో సాగింది.
రీబూట్ మెమరీని క్లియర్ చేసింది మరియు ప్రతిదీ క్రమంలో తిరిగి వచ్చింది.
ప్రత్యామ్నాయం లేకుండా చేయడం సాధ్యమేనా? అవును, కానీ దాడి జరిగినప్పుడు సేవ లేకుండా వినియోగదారులను వదిలివేసే ప్రమాదం ఉంది. వాస్తవానికి, వర్క్‌అరౌండ్‌ని ఉపయోగించడం వలన వినియోగదారుల కోసం సేవల్లో ఒకదానిని మందగించడంతో సహా పలు సమస్యలు ఎదురయ్యాయి, అయినప్పటికీ చర్యలు సమర్థించబడతాయని మేము విశ్వసిస్తున్నాము.
ఆండ్రీ టిమోఫీవ్‌కు చాలా ధన్యవాదాలు () విచారణను నిర్వహించడంలో సహాయం కోసం, అలాగే అలెక్సీ క్రేనెవ్ () - సర్వర్‌లలో సెంటోస్ మరియు కెర్నల్స్‌ను అప్‌డేట్ చేసే టైటానిక్ పని కోసం. ఈ సందర్భంలో ప్రారంభం నుండి చాలాసార్లు ప్రారంభించాల్సిన ప్రక్రియ, ఇది చాలా నెలలు ఎందుకు లాగబడింది.
మూలం: www.habr.com