DDoS-Guard ජාලයේ නීත්‍යානුකූල ගමනාගමනය මෑතකදී තත්පරයකට ගිගාබිට් සියයක් ඉක්මවිය. දැනට, අපගේ සියලුම ගමනාගමනයෙන් 50% ක් පාරිභෝගික වෙබ් සේවා මගින් ජනනය වේ. මේවා දස දහස් ගණනක වසම්, ඉතා වෙනස් සහ බොහෝ අවස්ථාවල තනි ප්‍රවේශයක් අවශ්ය වේ.
කප්පාදුව පහතින් දැක්වෙන්නේ අපි ඉදිරිපස නෝඩ් කළමනාකරණය කරන ආකාරය සහ අඩවි ලක්ෂ ගණනක් සඳහා SSL සහතික නිකුත් කරන ආකාරයයි.
එක් වෙබ් අඩවියක් සඳහා ඉදිරිපස සැකසීම, ඉතා විශාල එකක් වුවද, පහසුය. අපි nginx හෝ haproxy හෝ lighttpd ගන්නවා, මාර්ගෝපදේශ අනුව එය වින්‍යාස කර එය අමතක කරන්නෙමු. යමක් වෙනස් කිරීමට අවශ්ය නම්, අපි රීලෝඩ් එකක් කර නැවත අමතක කරමු.
ඔබ පියාසර කරන විට විශාල වාහන තදබදයක් සකසන විට, ඉල්ලීම්වල නීත්‍යානුකූල භාවය ඇගයීම, පරිශීලක අන්තර්ගතය සම්පීඩනය සහ හැඹිලිය, සහ ඒ සමඟම තත්පරයට කිහිප වතාවක් පරාමිතීන් වෙනස් කරන විට සියල්ල වෙනස් වේ. පරිශීලකයාට ඔහුගේ පුද්ගලික ගිණුමේ සැකසුම් වෙනස් කළ වහාම සියලුම බාහිර නෝඩ් වල ප්රතිඵලය දැකීමට අවශ්ය වේ. පරිශීලකයෙකුට API හරහා තනි ගමනාගමන සැකසුම් පරාමිතීන් සහිත වසම් දහස් ගණනක් (සහ සමහර විට දස දහස් ගණනක්) බාගත හැකිය. මේ සියල්ල ඇමරිකාවේ සහ යුරෝපයේ සහ ආසියාවේ වහාම ක්‍රියාත්මක විය යුතුය - මොස්කව්හි පමණක් භෞතිකව වෙන් කරන ලද පෙරීමේ නෝඩ් කිහිපයක් ඇති බව සලකන විට කාර්යය වඩාත්ම සුළු දෙයක් නොවේ.
ලොව පුරා විශාල විශ්වාසදායක නෝඩ් බොහොමයක් ඇත්තේ ඇයි?
-
සේවාලාභී ගමනාගමනය සඳහා වන සේවාවේ ගුණාත්මකභාවය - USA වෙතින් වන ඉල්ලීම් USA තුළ (ප්‍රහාර, විග්‍රහ කිරීම් සහ වෙනත් විෂමතා ඇතුළුව) සැකසීමට අවශ්ය වන අතර, මොස්කව් හෝ යුරෝපයට ඇද නොගෙන, සැකසීමේ ප්‍රමාදය අනපේක්ෂිත ලෙස වැඩි කරයි.
-
ප්‍රහාරක ගමනාගමනය ස්ථානගත කළ යුතුය - ප්‍රහාර වලදී සංක්‍රමණ ක්‍රියාකරුවන් පිරිහීමට ලක්විය හැක, එහි පරිමාව බොහෝ විට 1Tbps ඉක්මවයි. අත්ලාන්තික් සාගරයේ හෝ ට්‍රාන්ස්ඒසියානු සබැඳි හරහා ප්‍රහාරක ගමනාගමනය ප්‍රවාහනය කිරීම හොඳ අදහසක් නොවේ. "ඔබට ලැබෙන ප්‍රහාරවල පරිමාව අපට අනතුරුදායකයි" යනුවෙන් Tier-1 ක්‍රියාකරුවන් පැවසූ විට අපට සැබෑ අවස්ථා තිබුණි. ඒ නිසා අපි ලැබෙන ප්‍රවාහයන් ඔවුන්ගේ මූලාශ්‍රවලට හැකි තරම් සමීපව පිළිගනිමු.
-
සේවාව අඛණ්ඩව පවත්වාගෙන යාම සඳහා දැඩි අවශ්‍යතා - පිරිසිදු කිරීමේ මධ්‍යස්ථාන එකිනෙකා මත හෝ අපගේ වේගයෙන් වෙනස් වන ලෝකයේ ප්‍රාදේශීය සිදුවීම් මත රඳා නොසිටිය යුතුය. ඔබ සතියකට MMTS-11 මහල් 9ටම විදුලිය විසන්ධි කළාද? - ප්රශ්නයක් නැහැ. මෙම විශේෂිත ස්ථානයේ භෞතික සම්බන්ධතාවයක් නොමැති එක් සේවාදායකයෙකුට දුක් විඳින්නේ නැත, සහ වෙබ් සේවාවන් කිසිදු තත්වයක් යටතේ දුක් විඳින්නේ නැත.
මේ සියල්ල කළමනාකරණය කරන්නේ කෙසේද?
සේවා වින්‍යාසය හැකි ඉක්මනින් සියලුම ඉදිරිපස නෝඩ් වෙත බෙදා හැරිය යුතුය (ඉතාමත් ක්ෂණිකව). ඔබට සෑම වෙනස්කමකදීම පෙළ වින්‍යාසයන් ගෙන නැවත ගොඩනැංවීමට සහ ඩීමන් නැවත පණගැන්වීමට නොහැකිය - එම nginx විසින් ක්‍රියාවලි වසා දැමීම (වැඩකරු වසා දැමීම) තව විනාඩි කිහිපයක් (හෝ දිගු වෙබ්සොකට් සැසි තිබේ නම් පැය ගණනක්) තබා ගනී.
nginx වින්‍යාසය නැවත පූරණය කරන විට, පහත පින්තූරය තරමක් සාමාන්‍ය වේ:
මතක භාවිතය ගැන:
පැරණි කම්කරුවන් සම්බන්ධතා ගණන මත රේඛීයව රඳා නොපවතින මතකය ඇතුළුව මතකය අනුභව කරයි - මෙය සාමාන්‍ය දෙයකි. සේවාදායක සම්බන්ධතා වසා දැමූ විට, මෙම මතකය නිදහස් වේ.
nginx ආරම්භ වන විට මෙය ගැටළුවක් නොවූයේ ඇයි? HTTP/2, WebSocket නැත, දැවැන්ත දිගු තබාගැනීමේ සම්බන්ධතා නොතිබුණි. අපගේ වෙබ් ගමනාගමනයෙන් 70% ක් HTTP/2 වේ, එනම් ඉතා දිගු සම්බන්ධතා.
විසඳුම සරලයි - nginx භාවිතා නොකරන්න, පෙළ ගොනු මත පදනම්ව පෙරමුනු කළමනාකරණය නොකරන්න, සහ විනිවිද පෙනෙන නාලිකා හරහා සිප් කළ පෙළ වින්‍යාසයන් යැවීමෙන් වලකින්න. නාලිකා, ඇත්ත වශයෙන්ම, සහතික කර සහ වෙන් කර ඇත, නමුත් එය ඒවා කිසිදු අඩු මහාද්වීපික බවට පත් නොකරයි.
අපට අපගේම ඉදිරිපස සේවාදායක-ශේෂයක් ඇත, එහි අභ්‍යන්තරය මම පහත ලිපි වලින් කතා කරමි. එයට කළ හැකි ප්‍රධානම දෙය නම් පියාසර කරන විට තත්පරයකට වින්‍යාස වෙනස් කිරීම් දහස් ගණනක් යෙදීම, නැවත ආරම්භ කිරීම, රීලෝඩ් කිරීම, මතක පරිභෝජනයේ හදිසි වැඩිවීම් සහ ඒ සියල්ල නොමැතිව ය. මෙය Hot Code Reload වලට බෙහෙවින් සමාන ය, උදාහරණයක් ලෙස Erlang. දත්ත භූ-බෙදා හරින ලද යතුරු-අගය දත්ත ගබඩාවක ගබඩා කර ඇති අතර ඉදිරිපස ක්‍රියාකරුවන් විසින් වහාම කියවනු ලැබේ. එම. ඔබ මොස්කව්හි වෙබ් අතුරු මුහුණත හෝ API හරහා SSL සහතිකය උඩුගත කරන අතර තත්පර කිහිපයකින් එය ලොස් ඇන්ජලීස් හි අපගේ පිරිසිදු කිරීමේ මධ්‍යස්ථානය වෙත යාමට සූදානම් වේ. ලෝක යුද්ධයක් හදිසියේ සිදුවී ලොව පුරා අන්තර්ජාලය අතුරුදහන් වුවහොත්, අපගේ නෝඩ් ස්වයංක්‍රීයව ක්රියා කරන අතර ලොස් ඇන්ජලීස්-ඇම්ස්ටර්ඩෑම්-මොස්කව්, මොස්කව්-ඇම්ස්ටර්ඩෑම්-හොංකොං- කැපවූ නාලිකාවලින් එකක් වූ වහාම අපගේ නෝඩ් ස්වයංක්‍රීයව ක්රියා කරයි. ලොස්-ලොස් ලබා ගත හැක. ඇන්ජලීස් හෝ අවම වශයෙන් GRE උපස්ථ ආවරණවලින් එකක්.
මෙම යාන්ත්‍රණයම අපට එසැණින් සහතික නිකුත් කිරීමට සහ අපි සංකේතනය කරමු සහතික අලුත් කිරීමට ඉඩ සලසයි. ඉතා සරලව එය මේ ආකාරයට ක්රියා කරයි:
-
සහතිකයක් නොමැතිව (හෝ කල් ඉකුත් වූ සහතිකයක් සහිතව) අපගේ සේවාදායකයාගේ වසම සඳහා අවම වශයෙන් එක් HTTPS ඉල්ලීමක් අප දුටු විගස, ඉල්ලීම පිළිගත් බාහිර නෝඩය මෙය අභ්‍යන්තර සහතික කිරීමේ අධිකාරියට වාර්තා කරයි.
-
පරිශීලකයා Let's Encrypt නිකුත් කිරීම තහනම් කර නොමැති නම්, සහතික කිරීමේ අධිකාරිය CSR උත්පාදනය කරයි, LE වෙතින් තහවුරු කිරීමේ ටෝකනයක් ලබාගෙන එය සංකේතාත්මක නාලිකාවක් හරහා සියලුම පෙරමුණු වෙත යවයි. දැන් ඕනෑම නෝඩයකට LE වෙතින් වලංගු ඉල්ලීමක් තහවුරු කළ හැක.
-
සුළු මොහොතකින් නිවැරදි සහතිකය සහ පුද්ගලික යතුර අපට ලැබී ඒ ආකාරයෙන්ම පෙරමුණු වෙත යවනු ලැබේ. නැවතත්, ඩීමන් නැවත ආරම්භ නොකර
-
කල් ඉකුත්වන දිනට දින 7 කට පෙර, සහතිකය නැවත ලබා ගැනීමේ ක්රියා පටිපාටිය ආරම්භ වේ
දැන් අපි පරිශීලකයින්ට සම්පූර්ණයෙන්ම විනිවිද පෙනෙන, තත්‍ය කාලීනව 350k සහතික කරකවමු.
මාලාවේ පහත ලිපි වලින්, මම විශාල වෙබ් ගමනාගමනය තත්‍ය කාලීනව සැකසීමේ වෙනත් විශේෂාංග ගැන කතා කරමි - නිදසුනක් ලෙස, සංක්‍රමණ සේවාලාභීන් සඳහා සේවාවේ ගුණාත්මකභාවය වැඩි දියුණු කිරීම සඳහා අසම්පූර්ණ දත්ත භාවිතා කරමින් RTT විශ්ලේෂණය කිරීම සහ සාමාන්‍යයෙන් සංක්‍රමණ ගමනාගමනය ආරක්ෂා කිරීම ගැන ටෙරාබිට් ප්‍රහාර, ගමනාගමන තොරතුරු බෙදා හැරීම සහ එකතු කිරීම, WAF, පාහේ අසීමිත CDN සහ අන්තර්ගත බෙදා හැරීම ප්‍රශස්ත කිරීම සඳහා බොහෝ යාන්ත්‍රණ.
සමීක්ෂණයට සහභාගී විය හැක්කේ ලියාපදිංචි පරිශීලකයින්ට පමණි. කරුණාකර.
ඔබ මුලින්ම දැන ගැනීමට කැමති කුමක්ද?
-
14,3%වෙබ් ගමනාගමනයේ ගුණාත්මකභාවය පොකුරු කිරීම සහ විශ්ලේෂණය කිරීම සඳහා ඇල්ගොරිතම<3
-
33,3%DDoS-Guard7 balancers වල අභ්‍යන්තර
-
9,5%සංක්‍රමණ L3/L4 ගමනාගමනය ආරක්ෂා කිරීම2
-
0,0%සංක්‍රමණ තදබදය මත වෙබ් අඩවි ආරක්ෂා කිරීම0
-
14,3%වෙබ් යෙදුම් Firewall3
-
28,6%විග්‍රහ කිරීමෙන් සහ ක්ලික් කිරීමෙන් ආරක්ෂා වීම6
පරිශීලකයින් 21 දෙනෙක් ඡන්දය දුන්හ. පරිශීලකයින් 6 දෙනෙක් ඡන්දය දීමෙන් වැළකී සිටියහ.
මූලාශ්රය: www.habr.com