మీడియా కంటెంట్ లేకుండా ఆధునిక వెబ్ దాదాపుగా ఊహించలేము: దాదాపు ప్రతి అమ్మమ్మకు స్మార్ట్‌ఫోన్ ఉంది, ప్రతి ఒక్కరూ సోషల్ నెట్‌వర్క్‌లలో ఉన్నారు మరియు నిర్వహణలో పనికిరాని సమయం కంపెనీలకు ఖరీదైనది. కంపెనీ కథనం యొక్క ట్రాన్స్క్రిప్ట్ ఇక్కడ ఉంది ఆమె హార్డ్‌వేర్ సొల్యూషన్‌ని ఉపయోగించి ఫోటోల డెలివరీని ఎలా నిర్వహించింది, ప్రాసెస్‌లో ఆమెకు ఎలాంటి పనితీరు సమస్యలు ఎదురయ్యాయి, వాటికి కారణమేమిటి మరియు Nginx ఆధారంగా సాఫ్ట్‌వేర్ సొల్యూషన్‌ను ఉపయోగించి ఈ సమస్యలు ఎలా పరిష్కరించబడ్డాయి, అన్ని స్థాయిలలో తప్పు సహనాన్ని నిర్ధారిస్తుంది () మేము ఒలేగ్ కథ రచయితలకు ధన్యవాదాలు సమావేశంలో తమ అనుభవాన్ని పంచుకున్న ఎఫిమోవా మరియు అలెగ్జాండ్రా డైమోవా .
— మేము ఫోటోలను ఎలా నిల్వ చేస్తాము మరియు కాష్ చేయడం గురించి చిన్న పరిచయంతో ప్రారంభిద్దాం. మేము వాటిని నిల్వ చేసే పొరను కలిగి ఉన్నాము మరియు మేము ఫోటోలను కాష్ చేసే పొరను కలిగి ఉంటాము. అదే సమయంలో, మేము అధిక ట్రిక్ రేట్‌ను సాధించాలనుకుంటే మరియు నిల్వపై లోడ్‌ను తగ్గించాలనుకుంటే, ఒక వ్యక్తి వినియోగదారు యొక్క ప్రతి ఫోటో ఒక కాషింగ్ సర్వర్‌లో ఉండటం మాకు ముఖ్యం. లేకపోతే, మనకు ఎక్కువ సర్వర్లు ఉన్నందున మనం చాలా రెట్లు ఎక్కువ డిస్క్‌లను ఇన్‌స్టాల్ చేయాల్సి ఉంటుంది. మా ట్రిక్ రేటు దాదాపు 99%, అంటే, మేము మా నిల్వపై లోడ్‌ను 100 రెట్లు తగ్గిస్తున్నాము మరియు దీన్ని చేయడానికి, 10 సంవత్సరాల క్రితం, ఇవన్నీ నిర్మించబడుతున్నప్పుడు, మాకు 50 సర్వర్లు ఉన్నాయి. దీని ప్రకారం, ఈ ఫోటోలను అందించడానికి, ఈ సర్వర్లు అందించే 50 బాహ్య డొమైన్‌లు మాకు అవసరం.
సహజంగానే, ప్రశ్న వెంటనే తలెత్తింది: మా సర్వర్‌లలో ఒకటి డౌన్ అయి అందుబాటులో లేకుంటే, మనం ట్రాఫిక్‌లో ఏ భాగాన్ని కోల్పోతాము? మేము మార్కెట్‌లో ఉన్నవాటిని పరిశీలించి, హార్డ్‌వేర్ ముక్కను కొనాలని నిర్ణయించుకున్నాము, తద్వారా అది మా సమస్యలన్నింటినీ పరిష్కరిస్తుంది. ఎంపిక F5-నెట్‌వర్క్ కంపెనీ యొక్క పరిష్కారంపై పడింది (ఇది ఇటీవలే NGINX, Incని కొనుగోలు చేసింది): BIG-IP స్థానిక ట్రాఫిక్ మేనేజర్.
ఈ హార్డ్‌వేర్ భాగం (LTM) ఏమి చేస్తుంది: ఇది ఐరన్ రౌటర్, ఇది దాని బాహ్య పోర్ట్‌ల యొక్క ఐరన్ రిడెండెన్సీని చేస్తుంది మరియు నెట్‌వర్క్ టోపోలాజీ ఆధారంగా కొన్ని సెట్టింగ్‌లలో ట్రాఫిక్‌ను రూట్ చేయడానికి మరియు ఆరోగ్య తనిఖీలను చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఈ హార్డ్‌వేర్ భాగాన్ని ప్రోగ్రామ్ చేయడం మాకు ముఖ్యం. దీని ప్రకారం, నిర్దిష్ట కాష్ నుండి నిర్దిష్ట వినియోగదారు యొక్క ఫోటోగ్రాఫ్‌లు ఎలా అందించబడ్డాయి అనే తర్కాన్ని మేము వివరించగలము. ఇది ఎలా ఉంది? ఒక డొమైన్‌లో ఇంటర్నెట్‌ను చూసే హార్డ్‌వేర్ ముక్క ఉంది, ఒక IP, ssl ఆఫ్‌లోడ్ చేస్తుంది, http అభ్యర్థనలను అన్వయిస్తుంది, IRule నుండి కాష్ నంబర్‌ను ఎంచుకుంటుంది, ఎక్కడికి వెళ్లాలి మరియు ట్రాఫిక్‌ని అక్కడికి వెళ్లేలా చేస్తుంది. అదే సమయంలో, ఇది ఆరోగ్య తనిఖీలను చేస్తుంది మరియు ఏదైనా యంత్రం అందుబాటులో లేనట్లయితే, ఆ సమయంలో ట్రాఫిక్ ఒక బ్యాకప్ సర్వర్‌కు వెళ్లేలా మేము దానిని తయారు చేసాము. కాన్ఫిగరేషన్ దృక్కోణం నుండి, కొన్ని సూక్ష్మ నైపుణ్యాలు ఉన్నాయి, కానీ సాధారణంగా ప్రతిదీ చాలా సులభం: మేము కార్డ్‌ను నమోదు చేస్తాము, నెట్‌వర్క్‌లో మా IPకి నిర్దిష్ట సంఖ్య యొక్క కరస్పాండెన్స్, మేము పోర్ట్‌లు 80 లో వింటామని మేము చెప్తున్నాము. మరియు 443, సర్వర్ అందుబాటులో లేనట్లయితే, మీరు బ్యాకప్ వన్‌కి ట్రాఫిక్‌ని పంపవలసి ఉంటుందని మేము చెప్తున్నాము, ఈ సందర్భంలో 35వది, మరియు మేము ఈ నిర్మాణాన్ని ఎలా విడదీయాలి అనేదానిపై తర్కం యొక్క సమూహాన్ని వివరిస్తాము. ఒకే సమస్య ఏమిటంటే హార్డ్‌వేర్ ప్రోగ్రామ్ చేయబడిన భాష Tcl. ఎవరైనా దీన్ని గుర్తుంచుకుంటే... ప్రోగ్రామింగ్‌కు అనుకూలమైన భాష కంటే ఈ భాష రాయడానికి మాత్రమే ఎక్కువగా ఉంటుంది:
మేము ఏమి పొందాము? మేము మా మౌలిక సదుపాయాల యొక్క అధిక లభ్యతను నిర్ధారిస్తూ, మా ట్రాఫిక్ మొత్తాన్ని మార్గనిర్దేశం చేసే, ఆరోగ్య ప్రయోజనాలను అందించే మరియు కేవలం పని చేసే హార్డ్‌వేర్ భాగాన్ని అందుకున్నాము. అంతేకాకుండా, ఇది చాలా కాలం పాటు పనిచేస్తుంది: గత 10 సంవత్సరాలుగా దాని గురించి ఎటువంటి ఫిర్యాదులు లేవు. 2018 ప్రారంభం నాటికి, మేము ఇప్పటికే సెకనుకు దాదాపు 80 వేల ఫోటోలను పంపుతున్నాము. ఇది మా రెండు డేటా సెంటర్‌ల నుండి దాదాపు 80 గిగాబిట్ల ట్రాఫిక్.
అయితే…
2018 ప్రారంభంలో, మేము చార్ట్‌లలో ఒక అగ్లీ చిత్రాన్ని చూశాము: ఫోటోలను పంపడానికి తీసుకున్న సమయం స్పష్టంగా పెరిగింది. మరియు అది మాకు సరిపోవడం ఆగిపోయింది. సమస్య ఏమిటంటే, ఈ ప్రవర్తన ట్రాఫిక్ ఎక్కువగా ఉన్న సమయంలో మాత్రమే కనిపిస్తుంది - మా కంపెనీకి ఇది ఆదివారం నుండి సోమవారం వరకు రాత్రి. కానీ మిగిలిన సమయాల్లో సిస్టమ్ ఎప్పటిలాగే ప్రవర్తించింది, వైఫల్యం యొక్క సంకేతాలు లేవు.
అయినప్పటికీ, సమస్యను పరిష్కరించాల్సి వచ్చింది. మేము సాధ్యమయ్యే అడ్డంకులను గుర్తించాము మరియు వాటిని తొలగించడం ప్రారంభించాము. అన్నింటిలో మొదటిది, మేము బాహ్య అప్‌లింక్‌లను విస్తరించాము, అంతర్గత అప్‌లింక్‌ల పూర్తి ఆడిట్‌ను నిర్వహించాము మరియు సాధ్యమయ్యే అన్ని అడ్డంకులను కనుగొన్నాము. కానీ ఇవన్నీ స్పష్టమైన ఫలితాన్ని ఇవ్వలేదు, సమస్య అదృశ్యం కాలేదు.
ఫోటో కాష్‌ల పనితీరు కూడా సాధ్యమయ్యే మరొక అడ్డంకి. మరియు సమస్య వారితోనే ఉంటుందని మేము నిర్ణయించుకున్నాము. బాగా, మేము పనితీరును విస్తరించాము - ఫోటో కాష్‌లలో ప్రధానంగా నెట్‌వర్క్ పోర్ట్‌లు. కానీ మళ్లీ స్పష్టమైన మెరుగుదల కనిపించలేదు. చివరికి, మేము LTM పనితీరుపై చాలా శ్రద్ధ వహించాము మరియు ఇక్కడ మేము గ్రాఫ్‌లపై విచారకరమైన చిత్రాన్ని చూశాము: అన్ని CPUలపై లోడ్ సజావుగా సాగడం ప్రారంభమవుతుంది, కానీ అకస్మాత్తుగా పీఠభూమికి వస్తుంది. అదే సమయంలో, LTM ఆరోగ్య తనిఖీలు మరియు అప్‌లింక్‌లకు తగినంతగా ప్రతిస్పందించడం ఆపివేస్తుంది మరియు వాటిని యాదృచ్ఛికంగా ఆఫ్ చేయడం ప్రారంభిస్తుంది, ఇది తీవ్రమైన పనితీరు క్షీణతకు దారితీస్తుంది.
అంటే, మేము సమస్య యొక్క మూలాన్ని గుర్తించాము, అడ్డంకిని గుర్తించాము. మనం ఏం చేస్తాం అనేది నిర్ణయించుకోవాల్సి ఉంది.
మేము చేయగలిగే మొదటి, అత్యంత స్పష్టమైన విషయం ఏమిటంటే, LTMని ఆధునీకరించడం. కానీ ఇక్కడ కొన్ని సూక్ష్మ నైపుణ్యాలు ఉన్నాయి, ఎందుకంటే ఈ హార్డ్‌వేర్ చాలా ప్రత్యేకమైనది, మీరు సమీప సూపర్ మార్కెట్‌కి వెళ్లి కొనుగోలు చేయరు. ఇది ప్రత్యేక ఒప్పందం, ప్రత్యేక లైసెన్స్ ఒప్పందం మరియు దీనికి చాలా సమయం పడుతుంది. రెండవ ఎంపిక ఏమిటంటే, మీ కోసం ఆలోచించడం ప్రారంభించడం, మీ స్వంత భాగాలను ఉపయోగించి మీ స్వంత పరిష్కారాన్ని రూపొందించడం, ప్రాధాన్యంగా ఓపెన్ యాక్సెస్ ప్రోగ్రామ్‌ను ఉపయోగించడం. దీని కోసం మనం సరిగ్గా ఏమి ఎంచుకోవాలో మరియు ఈ సమస్యను పరిష్కరించడానికి మేము ఎంత సమయం వెచ్చిస్తామో నిర్ణయించుకోవడం మాత్రమే మిగిలి ఉంది, ఎందుకంటే వినియోగదారులు తగినంత ఫోటోలను అందుకోలేదు. అందువల్ల, మనం ఇవన్నీ చాలా చాలా త్వరగా చేయాలి, నిన్న ఒకరు అనవచ్చు.
పని "సాధ్యమైనంత త్వరగా మరియు మన వద్ద ఉన్న హార్డ్‌వేర్‌ను ఉపయోగించి" లాగా అనిపించినందున, మేము మొదట అనుకున్నది చాలా శక్తి లేని కొన్ని యంత్రాలను ముందు నుండి తీసివేసి, Nginxని అక్కడ ఉంచండి, దానితో ఎలా చేయాలో మాకు తెలుసు. పని చేయండి మరియు హార్డ్‌వేర్ చేసే లాజిక్‌లన్నింటినీ అమలు చేయడానికి ప్రయత్నించండి. అంటే, వాస్తవానికి, మేము మా హార్డ్‌వేర్‌ను విడిచిపెట్టాము, మేము కాన్ఫిగర్ చేయాల్సిన మరో 4 సర్వర్‌లను ఇన్‌స్టాల్ చేసాము, వాటి కోసం బాహ్య డొమైన్‌లను సృష్టించాము, ఇది 10 సంవత్సరాల క్రితం ఎలా ఉందో... ఈ మెషీన్‌లు పడిపోయినట్లయితే మేము కొద్దిగా లభ్యతను కోల్పోయాము, కానీ ఇంకా తక్కువ, వారు స్థానికంగా మా వినియోగదారుల సమస్యను పరిష్కరించారు.
దీని ప్రకారం, తర్కం అలాగే ఉంటుంది: మేము Nginxని ఇన్‌స్టాల్ చేస్తాము, ఇది SSL-ఆఫ్‌లోడ్ చేయగలదు, మేము ఏదో ఒకవిధంగా రౌటింగ్ లాజిక్, హెల్త్-చెక్‌లను కాన్ఫిగర్‌లలో ప్రోగ్రామ్ చేయవచ్చు మరియు మనకు ముందు ఉన్న లాజిక్‌ను నకిలీ చేయవచ్చు.
configs వ్రాయడానికి కూర్చుందాము. మొదట ప్రతిదీ చాలా సులభం అని అనిపించింది, కానీ, దురదృష్టవశాత్తు, ప్రతి పనికి మాన్యువల్‌లను కనుగొనడం చాలా కష్టం. అందువల్ల, “ఫోటోల కోసం Nginxని ఎలా కాన్ఫిగర్ చేయాలి” అని గూగ్లింగ్ చేయమని మేము సిఫార్సు చేయము: అధికారిక డాక్యుమెంటేషన్‌ను సూచించడం మంచిది, ఇది ఏ సెట్టింగ్‌లను తాకాలి అని చూపుతుంది. కానీ నిర్దిష్ట పరామితిని మీరే ఎంచుకోవడం మంచిది. బాగా, అప్పుడు ప్రతిదీ సులభం: మేము కలిగి ఉన్న సర్వర్‌లను వివరిస్తాము, మేము సర్టిఫికేట్‌లను వివరిస్తాము ... కానీ చాలా ఆసక్తికరమైన విషయం ఏమిటంటే, వాస్తవానికి, రూటింగ్ లాజిక్.
మొదట మనం మన లొకేషన్‌ను వివరిస్తున్నట్లు, అందులో ఉన్న ఫోటో కాష్ సంఖ్యను సరిపోల్చడం, మన చేతులు లేదా జనరేటర్‌ని ఉపయోగించి మనకు ఎన్ని అప్‌స్ట్రీమ్‌లు అవసరమో వివరించడం, ప్రతి అప్‌స్ట్రీమ్‌లో మేము ట్రాఫిక్ ఏ సర్వర్‌ని సూచిస్తున్నాము. వెళ్ళండి, మరియు బ్యాకప్ సర్వర్ - ప్రధాన సర్వర్ అందుబాటులో లేకుంటే:
కానీ, బహుశా, ప్రతిదీ చాలా సరళంగా ఉంటే, మేము ఇంటికి వెళ్లి ఏమీ అనలేము. దురదృష్టవశాత్తూ, డిఫాల్ట్ Nginx సెట్టింగ్‌లతో, సాధారణంగా, అనేక సంవత్సరాల అభివృద్ధిలో రూపొందించబడినవి మరియు ఈ సందర్భంలో పూర్తిగా సరిపోవు... కాన్ఫిగరేషన్ ఇలా కనిపిస్తుంది: కొన్ని అప్‌స్ట్రీమ్ సర్వర్‌లో అభ్యర్థన లోపం లేదా గడువు ముగిసినట్లయితే, Nginx ఎల్లప్పుడూ ట్రాఫిక్‌ని తదుపరి దానికి మారుస్తుంది. అంతేకాకుండా, మొదటి వైఫల్యం తర్వాత, 10 సెకన్లలోపు సర్వర్ కూడా ఆపివేయబడుతుంది, పొరపాటున మరియు గడువు ముగిసింది - ఇది ఏ విధంగానూ కాన్ఫిగర్ చేయబడదు. అంటే, మేము అప్‌స్ట్రీమ్ డైరెక్టివ్‌లో గడువు ముగింపు ఎంపికను తీసివేస్తే లేదా రీసెట్ చేస్తే, Nginx ఈ అభ్యర్థనను ప్రాసెస్ చేయనప్పటికీ మరియు కొన్ని చాలా మంచి లోపంతో ప్రతిస్పందించినప్పటికీ, సర్వర్ మూసివేయబడుతుంది.
దీన్ని నివారించడానికి, మేము రెండు పనులు చేసాము:
ఎ) వారు దీన్ని మాన్యువల్‌గా చేయకుండా Nginx ని నిషేధించారు - మరియు దురదృష్టవశాత్తు, దీన్ని చేయడానికి ఏకైక మార్గం గరిష్టంగా విఫలమయ్యే సెట్టింగ్‌లను సెట్ చేయడం.
బి) ఇతర ప్రాజెక్ట్‌లలో మేము బ్యాక్‌గ్రౌండ్ హెల్త్ చెక్‌లను చేయడానికి అనుమతించే మాడ్యూల్‌ను ఉపయోగిస్తామని మేము గుర్తుంచుకున్నాము - తదనుగుణంగా, మేము చాలా తరచుగా ఆరోగ్య తనిఖీలు చేసాము, తద్వారా ప్రమాదం జరిగినప్పుడు పనికిరాని సమయం తక్కువగా ఉంటుంది.
దురదృష్టవశాత్తూ, ఇది అంతా కాదు, ఎందుకంటే ఈ పథకం యొక్క మొదటి రెండు వారాల ఆపరేషన్ TCP ఆరోగ్య తనిఖీ కూడా నమ్మదగని విషయం అని చూపించింది: అప్‌స్ట్రీమ్ సర్వర్‌లో ఇది Nginx లేదా D-స్టేట్‌లోని Nginx కాకపోవచ్చు. ఈ సందర్భంలో కెర్నల్ కనెక్షన్‌ని అంగీకరిస్తుంది, ఆరోగ్య తనిఖీ పాస్ అవుతుంది, కానీ పని చేయదు. అందువల్ల, మేము దీన్ని వెంటనే హెల్త్-చెక్ httpతో భర్తీ చేసాము, నిర్దిష్టమైనదాన్ని తయారు చేసాము, అది 200ని తిరిగి ఇస్తే, ఈ స్క్రిప్ట్‌లో ప్రతిదీ పని చేస్తుంది. మీరు అదనపు లాజిక్ చేయవచ్చు - ఉదాహరణకు, కాషింగ్ సర్వర్‌ల విషయంలో, ఫైల్ సిస్టమ్ సరిగ్గా మౌంట్ చేయబడిందో లేదో తనిఖీ చేయండి:
మరియు ఇది మాకు సరిపోతుంది, ప్రస్తుతానికి సర్క్యూట్ హార్డ్‌వేర్ ఏమి చేసిందో పూర్తిగా పునరావృతం చేస్తుంది. కానీ మేం బాగా చేయాలనుకున్నాం. ఇంతకుముందు, మాకు ఒక బ్యాకప్ సర్వర్ ఉంది మరియు ఇది చాలా మంచిది కాదు, ఎందుకంటే మీకు వంద సర్వర్లు ఉంటే, ఒకేసారి అనేక విఫలమైనప్పుడు, ఒక బ్యాకప్ సర్వర్ లోడ్‌ను భరించే అవకాశం లేదు. అందువల్ల, మేము అన్ని సర్వర్‌లలో రిజర్వేషన్‌ను పంపిణీ చేయాలని నిర్ణయించుకున్నాము: మేము కేవలం మరొక ప్రత్యేక అప్‌స్ట్రీమ్‌ని చేసాము, అక్కడ ఉన్న అన్ని సర్వర్‌లను వారు అందించగల లోడ్‌కు అనుగుణంగా నిర్దిష్ట పారామితులతో వ్రాసాము, మేము ఇంతకు ముందు కలిగి ఉన్న అదే ఆరోగ్య తనిఖీలను జోడించాము:
ఒక అప్‌స్ట్రీమ్‌లో మరొక అప్‌స్ట్రీమ్‌కి వెళ్లడం అసాధ్యం కాబట్టి, మేము సరైన, అవసరమైన ఫోటో కాష్‌ను రికార్డ్ చేసిన మెయిన్ అప్‌స్ట్రీమ్ అందుబాటులో లేనట్లయితే, మేము ఫాల్‌బ్యాక్‌కి ఎర్రర్_పేజీ ద్వారా వెళ్లామని నిర్ధారించుకోవడం అవసరం. మేము బ్యాకప్ అప్‌స్ట్రీమ్‌కి ఎక్కడికి వెళ్లాము:
మరియు అక్షరాలా నాలుగు సర్వర్‌లను జోడించడం ద్వారా, ఇది మనకు లభించింది: మేము లోడ్‌లో కొంత భాగాన్ని భర్తీ చేసాము - మేము దానిని LTM నుండి ఈ సర్వర్‌లకు తీసివేసి, ప్రామాణిక హార్డ్‌వేర్ మరియు సాఫ్ట్‌వేర్‌ను ఉపయోగించి అక్కడ అదే లాజిక్‌ను అమలు చేసాము మరియు ఈ సర్వర్లు చేయగల బోనస్‌ను వెంటనే అందుకున్నాము. స్కేల్ చేయబడుతుంది, ఎందుకంటే అవి అవసరమైనంత ఎక్కువగా సరఫరా చేయబడతాయి. బాగా, ప్రతికూలత ఏమిటంటే, మేము బాహ్య వినియోగదారుల కోసం అధిక లభ్యతను కోల్పోయాము. కానీ ఆ సమయంలో మేము దీన్ని త్యాగం చేయాల్సి వచ్చింది, ఎందుకంటే సమస్యను వెంటనే పరిష్కరించాల్సిన అవసరం ఉంది. కాబట్టి, మేము లోడ్‌లో కొంత భాగాన్ని తీసివేసాము, ఆ సమయంలో అది దాదాపు 40%, LTM మంచి అనుభూతిని కలిగి ఉంది మరియు సమస్య ప్రారంభమైన రెండు వారాల తర్వాత, మేము సెకనుకు 45k అభ్యర్థనలను కాదు, 55k పంపడం ప్రారంభించాము. వాస్తవానికి, మేము 20% పెరిగాము - ఇది స్పష్టంగా మేము వినియోగదారుకు ఇవ్వని ట్రాఫిక్. మరియు ఆ తర్వాత వారు మిగిలిన సమస్యను ఎలా పరిష్కరించాలో ఆలోచించడం ప్రారంభించారు - అధిక బాహ్య ప్రాప్యతను నిర్ధారించడానికి.
మేము కొంత విరామం తీసుకున్నాము, ఈ సమయంలో మేము దీని కోసం ఏ పరిష్కారాన్ని ఉపయోగించాలో చర్చించాము. DNS ఉపయోగించి విశ్వసనీయతను నిర్ధారించడానికి ప్రతిపాదనలు ఉన్నాయి, కొన్ని హోమ్-వ్రాతపూర్వక స్క్రిప్ట్‌లు, డైనమిక్ రౌటింగ్ ప్రోటోకాల్‌లను ఉపయోగించడం... చాలా ఎంపికలు ఉన్నాయి, అయితే ఫోటోల యొక్క నిజమైన విశ్వసనీయ డెలివరీ కోసం, మీరు దీన్ని పర్యవేక్షించే మరొక పొరను పరిచయం చేయాల్సిన అవసరం ఉందని ఇప్పటికే స్పష్టమైంది. . మేము ఈ యంత్రాలను ఫోటో డైరెక్టర్లు అని పిలిచాము. మేము ఆధారపడిన సాఫ్ట్‌వేర్ Keepalived:
ప్రారంభించడానికి, Keepalived దేనిని కలిగి ఉంటుంది? మొదటిది VRRP ప్రోటోకాల్, ఇది నెట్‌వర్క్‌లకు విస్తృతంగా తెలుసు, ఇది క్లయింట్లు కనెక్ట్ అయ్యే బాహ్య IP చిరునామాకు తప్పు సహనాన్ని అందించే నెట్‌వర్క్ పరికరాలపై ఉంది. రెండవ భాగం IPVS, IP వర్చువల్ సర్వర్, ఫోటో రూటర్‌ల మధ్య బ్యాలెన్స్ చేయడానికి మరియు ఈ స్థాయిలో తప్పు సహనాన్ని నిర్ధారించడానికి. మరియు మూడవది - ఆరోగ్య తనిఖీలు.
మొదటి భాగంతో ప్రారంభిద్దాం: VRRP - ఇది ఎలా ఉంటుంది? క్లయింట్లు కనెక్ట్ అయ్యే dns badoocdn.comలో ఒక నిర్దిష్ట వర్చువల్ IP ఉంది. ఏదో ఒక సమయంలో, మేము ఒక సర్వర్‌లో IP చిరునామాను కలిగి ఉన్నాము. Keepalived ప్యాకెట్‌లు VRRP ప్రోటోకాల్ ద్వారా సర్వర్‌ల మధ్య నడుస్తాయి మరియు మాస్టర్ రాడార్ నుండి అదృశ్యమైతే - సర్వర్ రీబూట్ చేయబడింది లేదా మరేదైనా, బ్యాకప్ సర్వర్ స్వయంచాలకంగా ఈ IP చిరునామాను తీసుకుంటుంది - మాన్యువల్ చర్యలు అవసరం లేదు. మాస్టర్ మరియు బ్యాకప్ మధ్య వ్యత్యాసం ప్రధానంగా ప్రాధాన్యతనిస్తుంది: ఇది ఎంత ఎక్కువగా ఉంటే, యంత్రం మాస్టర్‌గా మారే అవకాశం ఎక్కువ. చాలా పెద్ద ప్రయోజనం ఏమిటంటే, మీరు సర్వర్‌లోనే IP చిరునామాలను కాన్ఫిగర్ చేయనవసరం లేదు, వాటిని కాన్ఫిగర్‌లో వివరించడానికి సరిపోతుంది మరియు IP చిరునామాలకు కొన్ని అనుకూల రూటింగ్ నియమాలు అవసరమైతే, ఇది నేరుగా కాన్ఫిగరేషన్‌లో వివరించబడింది VRRP ప్యాకేజీలో వివరించిన అదే వాక్యనిర్మాణం. మీకు తెలియని విషయాలు ఏవీ ఎదురుకావు.
ఇది ఆచరణలో ఎలా కనిపిస్తుంది? సర్వర్‌లలో ఒకటి విఫలమైతే ఏమి జరుగుతుంది? మాస్టర్ అదృశ్యమైన వెంటనే, మా బ్యాకప్ ప్రకటనలను స్వీకరించడం ఆగిపోతుంది మరియు స్వయంచాలకంగా మాస్టర్ అవుతుంది. కొంత సమయం తర్వాత, మేము మాస్టర్‌ను రిపేర్ చేసాము, రీబూట్ చేసాము, Keepalived పెంచాము - బ్యాకప్ కంటే ఎక్కువ ప్రాధాన్యతతో ప్రకటనలు వస్తాయి మరియు బ్యాకప్ స్వయంచాలకంగా వెనక్కి మారుతుంది, IP చిరునామాలను తీసివేస్తుంది, మాన్యువల్ చర్యలు చేయవలసిన అవసరం లేదు.
అందువలన, మేము బాహ్య IP చిరునామా యొక్క తప్పు సహనాన్ని నిర్ధారించాము. తర్వాతి భాగం బాహ్య IP చిరునామా నుండి ఇప్పటికే రద్దు చేస్తున్న ఫోటో రూటర్‌ల వరకు ట్రాఫిక్‌ను బ్యాలెన్స్ చేయడం. బ్యాలెన్సింగ్ ప్రోటోకాల్‌లతో ప్రతిదీ చాలా స్పష్టంగా ఉంది. ఇది సాధారణ రౌండ్-రాబిన్ లేదా కొంచెం సంక్లిష్టమైన విషయాలు, wrr, జాబితా కనెక్షన్ మరియు మొదలైనవి. ఇది ప్రాథమికంగా డాక్యుమెంటేషన్‌లో వివరించబడింది, ప్రత్యేకంగా ఏమీ లేదు. కానీ డెలివరీ పద్ధతి... మనం వాటిలో ఒకదాన్ని ఎందుకు ఎంచుకున్నామో ఇక్కడ మేము నిశితంగా పరిశీలిస్తాము. అవి NAT, డైరెక్ట్ రూటింగ్ మరియు TUN. వాస్తవం ఏమిటంటే, మేము వెంటనే సైట్‌ల నుండి 100 గిగాబిట్ల ట్రాఫిక్‌ను అందించాలని ప్లాన్ చేసాము. మీరు అంచనా వేస్తే, మీకు 10 గిగాబిట్ కార్డ్‌లు అవసరం, సరియైనదా? ఒక సర్వర్‌లోని 10 గిగాబిట్ కార్డ్‌లు ఇప్పటికే మా “ప్రామాణిక పరికరాలు” అనే భావనకు మించి ఉన్నాయి. ఆపై మేము కొంత ట్రాఫిక్‌ను మాత్రమే ఇవ్వమని, మేము ఫోటోలను ఇస్తామని గుర్తుచేసుకున్నాము.
ప్రత్యేకత ఏమిటి? - ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ ట్రాఫిక్ మధ్య అపారమైన వ్యత్యాసం. ఇన్‌కమింగ్ ట్రాఫిక్ చాలా చిన్నది, అవుట్‌గోయింగ్ ట్రాఫిక్ చాలా పెద్దది:
ఈ గ్రాఫ్‌లను పరిశీలిస్తే, దర్శకుడు సెకనుకు దాదాపు 200 MB అందుకుంటున్న తరుణంలో ఇది చాలా సాధారణమైన రోజు. మేము సెకనుకు 4,500 MBని తిరిగి ఇస్తాము, మా నిష్పత్తి సుమారు 1/22. 22 వర్కర్ సర్వర్‌లకు అవుట్‌గోయింగ్ ట్రాఫిక్‌ను పూర్తిగా అందించడానికి, ఈ కనెక్షన్‌ని ఆమోదించే ఒకటి మాత్రమే మాకు అవసరం అని ఇప్పటికే స్పష్టంగా ఉంది. ఇక్కడే డైరెక్ట్ రూటింగ్ అల్గోరిథం మన సహాయానికి వస్తుంది.
ఇది ఎలా ఉంది? మా ఫోటో డైరెక్టర్, అతని టేబుల్ ప్రకారం, ఫోటో రౌటర్లకు కనెక్షన్లను ప్రసారం చేస్తాడు. కానీ ఫోటో రౌటర్లు నేరుగా ఇంటర్నెట్‌కి రిటర్న్ ట్రాఫిక్‌ను పంపుతాయి, క్లయింట్‌కు పంపండి, ఫోటో డైరెక్టర్ ద్వారా తిరిగి వెళ్లదు, అందువల్ల, కనీస సంఖ్యలో యంత్రాలతో, మేము పూర్తి తప్పు సహనం మరియు అన్ని ట్రాఫిక్‌ను పంపింగ్ చేస్తాము. కాన్ఫిగరేషన్‌లలో ఇది ఇలా కనిపిస్తుంది: మేము అల్గోరిథంను నిర్దేశిస్తాము, మా విషయంలో ఇది సాధారణ rr, ప్రత్యక్ష రౌటింగ్ పద్ధతిని అందించండి మరియు ఆపై అన్ని నిజమైన సర్వర్‌లను జాబితా చేయడం ప్రారంభించండి, వాటిలో ఎన్ని ఉన్నాయి. ఏది ఈ ట్రాఫిక్‌ని నిర్ణయిస్తుంది. మనకు అక్కడ ఒకటి లేదా రెండు సర్వర్లు లేదా అనేక సర్వర్లు ఉంటే, అటువంటి అవసరం ఏర్పడుతుంది - మేము ఈ విభాగాన్ని కాన్ఫిగరేషన్‌కు జోడిస్తాము మరియు పెద్దగా చింతించకండి. నిజమైన సర్వర్‌ల వైపు నుండి, ఫోటో రౌటర్ వైపు నుండి, ఈ పద్ధతికి చాలా తక్కువ కాన్ఫిగరేషన్ అవసరం, ఇది డాక్యుమెంటేషన్‌లో ఖచ్చితంగా వివరించబడింది మరియు అక్కడ ఆపదలు లేవు.
ముఖ్యంగా మంచి విషయం ఏమిటంటే, అటువంటి పరిష్కారం స్థానిక నెట్‌వర్క్ యొక్క సమూలమైన రీడిజైన్‌ను సూచించదు; ఇది మాకు ముఖ్యమైనది; మేము దీన్ని తక్కువ ఖర్చులతో పరిష్కరించాల్సి వచ్చింది. మీరు చూస్తే , అప్పుడు అది ఎలా ఉంటుందో చూద్దాం. ఇక్కడ మేము ఒక నిర్దిష్ట వర్చువల్ సర్వర్‌ని కలిగి ఉన్నాము, పోర్ట్ 443లో, వింటుంది, కనెక్షన్‌ని అంగీకరిస్తుంది, అన్ని పని చేసే సర్వర్లు జాబితా చేయబడ్డాయి మరియు కనెక్షన్, ఇవ్వండి లేదా తీసుకోండి, అదే విధంగా ఉందని మీరు చూడవచ్చు. మేము అదే వర్చువల్ సర్వర్‌లోని గణాంకాలను పరిశీలిస్తే, మనకు ఇన్‌కమింగ్ ప్యాకెట్‌లు, ఇన్‌కమింగ్ కనెక్షన్‌లు ఉన్నాయి, కానీ ఖచ్చితంగా అవుట్‌గోయింగ్ లేవు. అవుట్‌గోయింగ్ కనెక్షన్‌లు నేరుగా క్లయింట్‌కి వెళ్తాయి. సరే, మేము దానిని అసమతుల్యత చేయగలిగాము. ఇప్పుడు, మా ఫోటో రూటర్‌లలో ఒకటి విఫలమైతే ఏమి జరుగుతుంది? అన్ని తరువాత, ఇనుము ఇనుము. ఇది కెర్నల్ భయాందోళనలకు గురికావచ్చు, అది విరిగిపోవచ్చు, విద్యుత్ సరఫరా కాలిపోవచ్చు. ఏదైనా. అందుకే ఆరోగ్య పరీక్షలు అవసరం. వ్యాపార లాజిక్‌ను కూడా తనిఖీ చేసే కొన్ని హోమ్-వ్రాత స్క్రిప్ట్‌ల వరకు పోర్ట్ ఎలా తెరిచి ఉందో లేదా మరింత క్లిష్టంగా ఉండేదాన్ని తనిఖీ చేయడం వంటి వాటిని సులభంగా చేయవచ్చు.
మేము మధ్యలో ఎక్కడో ఆపివేసాము: మాకు ఒక నిర్దిష్ట స్థానానికి https అభ్యర్థన ఉంది, స్క్రిప్ట్ అంటారు, ఇది 200వ ప్రతిస్పందనతో ప్రతిస్పందిస్తే, ఈ సర్వర్‌తో అంతా బాగానే ఉందని, ఇది సజీవంగా ఉందని మరియు చాలా వరకు ఆన్ చేయవచ్చని మేము విశ్వసిస్తున్నాము. సులభంగా.
ఇది మళ్ళీ ఆచరణలో ఎలా కనిపిస్తుంది? నిర్వహణ కోసం సర్వర్‌ను ఆఫ్ చేద్దాం - ఉదాహరణకు, BIOS ను ఫ్లాషింగ్ చేయండి. లాగ్‌లలో, మనకు వెంటనే సమయం ముగిసింది, మేము మొదటి పంక్తిని చూస్తాము, ఆపై మూడు ప్రయత్నాల తర్వాత అది "విఫలమైంది" అని గుర్తించబడింది మరియు ఇది జాబితా నుండి తీసివేయబడుతుంది.
రెండవ ప్రవర్తన ఎంపిక కూడా సాధ్యమే, VS కేవలం సున్నాకి సెట్ చేయబడినప్పుడు, కానీ ఫోటో తిరిగి ఇవ్వబడినట్లయితే, ఇది బాగా పని చేయదు. సర్వర్ వస్తుంది, Nginx అక్కడ ప్రారంభమవుతుంది, ఆరోగ్య తనిఖీ వెంటనే కనెక్షన్ పని చేస్తుందని, ప్రతిదీ బాగానే ఉందని మరియు సర్వర్ మా జాబితాలో కనిపిస్తుంది మరియు లోడ్ వెంటనే దానికి వర్తింపజేయడం ప్రారంభమవుతుంది. డ్యూటీ అడ్మినిస్ట్రేటర్ నుండి ఎటువంటి మాన్యువల్ చర్యలు అవసరం లేదు. రాత్రికి సర్వర్ రీబూట్ చేయబడింది - మానిటరింగ్ డిపార్ట్‌మెంట్ రాత్రి దీని గురించి మాకు కాల్ చేయదు. ఇది జరిగిందని, అంతా బాగానే ఉందని వారు మీకు తెలియజేస్తారు.
కాబట్టి, చాలా సరళమైన మార్గంలో, తక్కువ సంఖ్యలో సర్వర్‌ల సహాయంతో, మేము బాహ్య లోపం సహనం యొక్క సమస్యను పరిష్కరించాము.
చెప్పవలసింది ఏమిటంటే, ఇవన్నీ పర్యవేక్షించాల్సిన అవసరం ఉంది. విడిగా, Keepalivede, చాలా కాలం క్రితం వ్రాసిన సాఫ్ట్‌వేర్‌గా, DBus, SMTP, SNMP మరియు ప్రామాణిక Zabbix ద్వారా తనిఖీలను ఉపయోగించి దీన్ని పర్యవేక్షించడానికి అనేక మార్గాలను కలిగి ఉందని గమనించాలి. అదనంగా, దాదాపు ప్రతి తుమ్ముకు అక్షరాలు ఎలా వ్రాయాలో అతనికి తెలుసు, మరియు నిజాయితీగా చెప్పాలంటే, ఏదో ఒక సమయంలో మేము దానిని ఆఫ్ చేయాలని కూడా అనుకున్నాము, ఎందుకంటే అతను ఏదైనా ట్రాఫిక్ మారడానికి, స్విచ్ ఆన్ చేయడానికి, ప్రతి IP కనెక్షన్ కోసం చాలా లేఖలు వ్రాస్తాడు. మరియు అందువలన న . వాస్తవానికి, చాలా సర్వర్లు ఉంటే, మీరు ఈ అక్షరాలతో మిమ్మల్ని మీరు ముంచెత్తవచ్చు. మేము ప్రామాణిక పద్ధతులను ఉపయోగించి ఫోటో రౌటర్‌లలో nginxని పర్యవేక్షిస్తాము మరియు హార్డ్‌వేర్ పర్యవేక్షణ దూరంగా లేదు. వాస్తవానికి, మేము మరో రెండు విషయాలను సలహా ఇస్తాము: ముందుగా, బాహ్య ఆరోగ్య తనిఖీలు మరియు లభ్యత, ఎందుకంటే ప్రతిదీ పనిచేసినప్పటికీ, వాస్తవానికి, బాహ్య ప్రొవైడర్‌లతో సమస్యలు లేదా మరింత సంక్లిష్టమైన వాటి కారణంగా వినియోగదారులు ఫోటోలను అందుకోలేరు. మీ సర్వర్‌లను బయటి నుండి పింగ్ చేయగల ప్రత్యేక మెషీన్‌ను మరొక నెట్‌వర్క్‌లో, అమెజాన్‌లో లేదా మరెక్కడైనా ఉంచడం ఎల్లప్పుడూ విలువైనదే, మరియు గమ్మత్తైన మెషిన్ లెర్నింగ్ ఎలా చేయాలో తెలిసిన వారికి, లేదా సాధారణ పర్యవేక్షణ, కనీసం అభ్యర్థనలు బాగా పడిపోయాయా లేదా దానికి విరుద్ధంగా పెరిగినా ట్రాక్ చేయడానికి. ఇది కూడా ఉపయోగకరంగా ఉంటుంది.
సంగ్రహంగా చెప్పండి: వాస్తవానికి, మేము ఇనుముతో కప్పబడిన పరిష్కారాన్ని భర్తీ చేసాము, ఇది ఏదో ఒక సమయంలో మనకు సరిపోయేలా ఆగిపోయింది, ప్రతిదీ ఒకే విధంగా చేసే చాలా సరళమైన సిస్టమ్‌తో, అంటే, ఇది HTTPS ట్రాఫిక్‌ను ముగించడం మరియు మరింత స్మార్ట్ రూటింగ్‌ను అందిస్తుంది అవసరమైన ఆరోగ్య తనిఖీలు. మేము ఈ సిస్టమ్ యొక్క స్థిరత్వాన్ని పెంచాము, అనగా, ప్రతి లేయర్‌కు మేము ఇప్పటికీ అధిక లభ్యతను కలిగి ఉన్నాము, అంతేకాకుండా ప్రతి లేయర్‌లో అన్నింటినీ స్కేల్ చేయడం చాలా సులభం అని మాకు బోనస్ ఉంది, ఎందుకంటే ఇది ప్రామాణిక సాఫ్ట్‌వేర్‌తో కూడిన ప్రామాణిక హార్డ్‌వేర్, అంటే , మేము సాధ్యమయ్యే సమస్యల నిర్ధారణను సరళీకృతం చేసాము.
మనం దేనితో ముగించాము? 2018 జనవరి సెలవుల్లో మాకు సమస్య ఉంది. మేము ఈ పథకాన్ని అమలులోకి తెచ్చిన మొదటి ఆరు నెలల్లో, LTM నుండి మొత్తం ట్రాఫిక్‌ను తీసివేయడానికి మేము దీన్ని అన్ని ట్రాఫిక్‌లకు విస్తరించాము, మేము ఒక డేటా సెంటర్‌లో 40 గిగాబిట్ల నుండి 60 గిగాబిట్‌లకు మరియు అదే సమయంలో ట్రాఫిక్‌లో మాత్రమే పెరిగాము. 2018 సంవత్సరం మొత్తం సెకనుకు దాదాపు మూడు రెట్లు ఎక్కువ ఫోటోలను పంపగలిగారు.
మూలం: www.habr.com