DDoS-Guard நெட்வொர்க்கில் முறையான போக்குவரத்து சமீபத்தில் ஒரு வினாடிக்கு நூறு ஜிகாபிட்களை தாண்டியது. தற்போது, எங்கள் ட்ராஃபிக்கில் 50% கிளையன்ட் இணைய சேவைகளால் உருவாக்கப்படுகிறது. இவை பல பல்லாயிரக்கணக்கான டொமைன்கள், மிகவும் வேறுபட்டவை மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் தனிப்பட்ட அணுகுமுறை தேவைப்படும்.
நூறாயிரக்கணக்கான தளங்களுக்கு முன் முனைகளை நாங்கள் எவ்வாறு நிர்வகிப்பது மற்றும் SSL சான்றிதழ்களை வழங்குவது என்பது வெட்டுக்குக் கீழே உள்ளது.
ஒரு தளத்திற்கு முன்புறத்தை அமைப்பது, மிகப் பெரியது கூட, எளிதானது. நாங்கள் nginx அல்லது haproxy அல்லது lighttpd ஐ எடுத்துக்கொள்கிறோம், வழிகாட்டிகளின்படி அதை உள்ளமைத்து அதை மறந்துவிடுகிறோம். நாம் ஏதாவது மாற்ற வேண்டும் என்றால், மீண்டும் ஏற்றி மீண்டும் மறந்து விடுகிறோம்.
நீங்கள் பறக்கும்போது பெரிய அளவிலான போக்குவரத்தை செயலாக்கும்போது, கோரிக்கைகளின் நியாயத்தன்மையை மதிப்பிடும்போது, பயனர் உள்ளடக்கத்தை சுருக்கி மற்றும் தற்காலிகமாக சேமிக்கும்போது, அதே நேரத்தில் அளவுருக்களை வினாடிக்கு பல முறை மாற்றும்போது எல்லாம் மாறும். பயனர் தனது தனிப்பட்ட கணக்கில் அமைப்புகளை மாற்றிய உடனேயே அனைத்து வெளிப்புற முனைகளிலும் முடிவைப் பார்க்க விரும்புகிறார். API வழியாக தனிப்பட்ட போக்குவரத்து செயலாக்க அளவுருக்கள் கொண்ட பல ஆயிரம் (மற்றும் சில நேரங்களில் பல்லாயிரக்கணக்கான) டொமைன்களையும் ஒரு பயனர் பதிவிறக்கம் செய்யலாம். இவை அனைத்தும் அமெரிக்காவிலும், ஐரோப்பாவிலும், ஆசியாவிலும் உடனடியாக வேலை செய்ய வேண்டும் - மாஸ்கோவில் மட்டும் பல உடல் ரீதியாக பிரிக்கப்பட்ட வடிகட்டுதல் முனைகள் உள்ளன என்பதைக் கருத்தில் கொண்டு, பணி மிகவும் அற்பமானது அல்ல.
உலகம் முழுவதும் ஏன் பல பெரிய நம்பகமான முனைகள் உள்ளன?
-
கிளையன்ட் டிராஃபிக்கிற்கான சேவையின் தரம் - அமெரிக்காவிலிருந்து வரும் கோரிக்கைகள் அமெரிக்காவில் செயலாக்கப்பட வேண்டும் (தாக்குதல்கள், பாகுபடுத்துதல் மற்றும் பிற முரண்பாடுகள் உட்பட), மேலும் மாஸ்கோ அல்லது ஐரோப்பாவிற்கு இழுக்கப்படாமல், செயலாக்க தாமதத்தை கணிக்க முடியாத அளவிற்கு அதிகரிக்கும்.
-
தாக்குதல் போக்குவரத்தை உள்ளூர்மயமாக்க வேண்டும் - தாக்குதல்களின் போது டிரான்ஸிட் ஆபரேட்டர்கள் சிதைந்து போகலாம், இதன் அளவு பெரும்பாலும் 1Tbps ஐ விட அதிகமாக இருக்கும். அட்லாண்டிக் அல்லது நாடுகடந்த இணைப்புகள் வழியாக தாக்குதல் போக்குவரத்தை கொண்டு செல்வது நல்ல யோசனையல்ல. "நீங்கள் பெறும் தாக்குதல்களின் அளவு எங்களுக்கு ஆபத்தானது" என்று அடுக்கு-1 ஆபரேட்டர்கள் கூறியபோது எங்களிடம் உண்மையான வழக்குகள் இருந்தன. அதனால்தான் உள்வரும் ஸ்ட்ரீம்களை அவற்றின் ஆதாரங்களுக்கு முடிந்தவரை நெருக்கமாக ஏற்றுக்கொள்கிறோம்.
-
சேவையின் தொடர்ச்சிக்கான கடுமையான தேவைகள் - துப்புரவு மையங்கள் ஒன்றுக்கொன்று சார்ந்து இருக்கக்கூடாது அல்லது நமது வேகமாக மாறிவரும் உலகில் உள்ளூர் நிகழ்வுகள் சார்ந்து இருக்கக்கூடாது. MMTS-11 இன் அனைத்து 9 தளங்களுக்கும் ஒரு வாரத்திற்கு மின்சாரத்தை துண்டித்தீர்களா? - எந்த பிரச்சினையும் இல்லை. இந்த குறிப்பிட்ட இடத்தில் உடல் இணைப்பு இல்லாத ஒரு வாடிக்கையாளரும் பாதிக்கப்பட மாட்டார்கள், எந்த சூழ்நிலையிலும் இணைய சேவைகள் பாதிக்கப்படாது.
இதையெல்லாம் எப்படி நிர்வகிப்பது?
சேவை உள்ளமைவுகள் அனைத்து முன் முனைகளிலும் கூடிய விரைவில் (உடனடியாக) விநியோகிக்கப்பட வேண்டும். ஒவ்வொரு மாற்றத்திலும் நீங்கள் உரை கட்டமைப்புகளை எடுத்து மீண்டும் உருவாக்க முடியாது மற்றும் டெமான்களை மறுதொடக்கம் செய்ய முடியாது - அதே nginx இன்னும் சில நிமிடங்களுக்கு (அல்லது நீண்ட வெப்சாக்கெட் அமர்வுகள் இருந்தால் மணிநேரங்களுக்கு) செயல்முறைகளை நிறுத்துகிறது (பணியாளர் மூடுகிறார்).
nginx உள்ளமைவை மீண்டும் ஏற்றும்போது, பின்வரும் படம் மிகவும் சாதாரணமானது:
நினைவக பயன்பாட்டில்:
பழைய தொழிலாளர்கள் நினைவகத்தை சாப்பிடுகிறார்கள், நினைவகம் உட்பட, இணைப்புகளின் எண்ணிக்கையை நேரியல் சார்ந்து இல்லை - இது சாதாரணமானது. கிளையன்ட் இணைப்புகள் மூடப்பட்டால், இந்த நினைவகம் விடுவிக்கப்படும்.
nginx தொடங்கும் போது இது ஏன் ஒரு பிரச்சனையாக இருக்கவில்லை? HTTP/2 இல்லை, WebSocket இல்லை, பாரிய நெடுங்கால இணைப்புகள் இல்லை. எங்கள் இணைய போக்குவரத்தில் 70% HTTP/2 ஆகும், அதாவது மிக நீண்ட இணைப்புகள்.
தீர்வு எளிதானது - nginx ஐப் பயன்படுத்த வேண்டாம், உரைக் கோப்புகளின் அடிப்படையில் முன்பக்கங்களை நிர்வகிக்க வேண்டாம், மேலும் டிரான்ஸ்பாசிஃபிக் சேனல்களில் ஜிப் செய்யப்பட்ட உரை உள்ளமைவுகளை நிச்சயமாக அனுப்ப வேண்டாம். சேனல்கள், நிச்சயமாக, உத்தரவாதம் மற்றும் ஒதுக்கப்பட்டவை, ஆனால் அது அவற்றைக் கண்டம் தாண்டியதாக மாற்றாது.
எங்களிடம் எங்கள் சொந்த முன் சர்வர்-பேலன்சர் உள்ளது, அதன் உள்நிலைகளை நான் பின்வரும் கட்டுரைகளில் பேசுவேன். மறுதொடக்கம், மறுஏற்றம், நினைவக நுகர்வு திடீர் அதிகரிப்பு மற்றும் இவை அனைத்தும் இல்லாமல், பறக்கும்போது வினாடிக்கு ஆயிரக்கணக்கான உள்ளமைவு மாற்றங்களைப் பயன்படுத்துவது இது செய்யக்கூடிய முக்கிய விஷயம். இது ஹாட் கோட் ரீலோடுக்கு மிகவும் ஒத்திருக்கிறது, எடுத்துக்காட்டாக எர்லாங்கில். தரவு புவி-பகிர்வு செய்யப்பட்ட விசை மதிப்பு தரவுத்தளத்தில் சேமிக்கப்பட்டு, முன் ஆக்சுவேட்டர்களால் உடனடியாகப் படிக்கப்படும். அந்த. மாஸ்கோவில் உள்ள வலை இடைமுகம் அல்லது API வழியாக SSL சான்றிதழைப் பதிவேற்றுகிறீர்கள், மேலும் சில நொடிகளில் லாஸ் ஏஞ்சல்ஸில் உள்ள எங்கள் துப்புரவு மையத்திற்குச் செல்ல தயாராக உள்ளது. ஒரு உலகப் போர் திடீரென நடந்து, உலகம் முழுவதும் இணையம் மறைந்து விட்டால், லாஸ் ஏஞ்சல்ஸ்-ஆம்ஸ்டர்டாம்-மாஸ்கோ, மாஸ்கோ-ஆம்ஸ்டர்டாம்-ஹாங்காங்- என்ற பிரத்யேக சேனல்களில் ஒன்றான உடனேயே நமது கணுக்கள் தன்னிச்சையாக இயங்கி மூளையின் பிளவை சரி செய்யும். லாஸ்-லாஸ் கிடைக்கும். ஏஞ்சல்ஸ் அல்லது குறைந்தபட்சம் GRE காப்பு மேலடுக்குகளில் ஒன்று.
இதே பொறிமுறையானது லெட்ஸ் என்க்ரிப்ட் சான்றிதழ்களை உடனடியாக வழங்கவும் புதுப்பிக்கவும் அனுமதிக்கிறது. மிகவும் எளிமையாக இது இப்படி வேலை செய்கிறது:
-
சான்றிதழில்லாமல் (அல்லது காலாவதியான சான்றிதழுடன்) எங்கள் கிளையண்டின் டொமைனுக்கான குறைந்தபட்சம் ஒரு HTTPS கோரிக்கையைப் பார்த்தவுடன், கோரிக்கையை ஏற்றுக்கொண்ட வெளிப்புற முனை உள் சான்றிதழ் அதிகாரிக்கு புகாரளிக்கும்.
-
லெட்ஸ் என்க்ரிப்ட் வழங்குவதை பயனர் தடைசெய்யவில்லை என்றால், சான்றிதழ் ஆணையம் ஒரு CSR ஐ உருவாக்கி, LE இலிருந்து ஒரு உறுதிப்படுத்தல் டோக்கனைப் பெற்று, மறைகுறியாக்கப்பட்ட சேனல் மூலம் எல்லா முனைகளுக்கும் அனுப்புகிறது. இப்போது எந்த முனையும் LE இலிருந்து சரிபார்க்கும் கோரிக்கையை உறுதிப்படுத்த முடியும்.
-
சில நிமிடங்களில், சரியான சான்றிதழையும் தனிப்பட்ட விசையையும் பெற்று, அதே வழியில் முனைகளுக்கு அனுப்புவோம். மீண்டும், டெமான்களை மறுதொடக்கம் செய்யாமல்
-
காலாவதி தேதிக்கு 7 நாட்களுக்கு முன்பு, சான்றிதழை மீண்டும் பெறுவதற்கான நடைமுறை தொடங்கப்படுகிறது
இப்போது நாங்கள் 350k சான்றிதழ்களை நிகழ்நேரத்தில் சுழற்றுகிறோம், பயனர்களுக்கு முற்றிலும் வெளிப்படையானது.
தொடரின் பின்வரும் கட்டுரைகளில், பெரிய இணைய போக்குவரத்தின் நிகழ்நேர செயலாக்கத்தின் பிற அம்சங்களைப் பற்றி நான் பேசுவேன் - எடுத்துக்காட்டாக, ட்ரான்ஸிட் வாடிக்கையாளர்களுக்கான சேவையின் தரத்தை மேம்படுத்த முழுமையற்ற தரவைப் பயன்படுத்தி RTT பகுப்பாய்வு செய்வது மற்றும் பொதுவாக டிரான்ஸிட் ட்ராஃபிக்கைப் பாதுகாப்பது பற்றி டெராபிட் தாக்குதல்கள், போக்குவரத்து தகவல்களின் விநியோகம் மற்றும் ஒருங்கிணைப்பு, WAF, கிட்டத்தட்ட வரம்பற்ற CDN மற்றும் உள்ளடக்க விநியோகத்தை மேம்படுத்துவதற்கான பல வழிமுறைகள்.
பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். , தயவு செய்து.
நீங்கள் முதலில் என்ன தெரிந்து கொள்ள விரும்புகிறீர்கள்?
-
14,3%வலை போக்குவரத்தின் தரத்தை கிளஸ்டரிங் மற்றும் பகுப்பாய்வு செய்வதற்கான அல்காரிதங்கள்<3
-
33,3%DDoS-Guard7 பேலன்சர்களின் உட்புறங்கள்
-
9,5%போக்குவரத்து L3/L4 போக்குவரத்தின் பாதுகாப்பு2
-
0,0%ட்ரான்ஸிட் டிராஃபிக்கில் இணையதளங்களைப் பாதுகாத்தல்0
-
14,3%இணைய பயன்பாட்டு ஃபயர்வால்3
-
28,6%பாகுபடுத்துதல் மற்றும் கிளிக் செய்வதிலிருந்து பாதுகாப்பு6
21 பயனர்கள் வாக்களித்துள்ளனர். 6 பயனர்கள் வாக்களிக்கவில்லை.
ஆதாரம்: www.habr.com