DDoS-Guard ցանցի օրինական տրաֆիկը վերջերս գերազանցել է վայրկյանում հարյուր գիգաբիթը: Ներկայումս մեր ամբողջ տրաֆիկի 50%-ը ստեղծվում է հաճախորդի վեբ ծառայություններից: Սրանք տասնյակ հազարավոր տիրույթներ են, որոնք շատ տարբեր են և շատ դեպքերում պահանջում են անհատական մոտեցում:
Ներքևում ներկայացված է, թե ինչպես ենք մենք կառավարում առջևի հանգույցները և թողարկում SSL վկայագրեր հարյուր հազարավոր կայքերի համար:
Մեկ կայքի համար ճակատ ստեղծելը, նույնիսկ շատ մեծ, հեշտ է: Մենք վերցնում ենք nginx կամ haproxy կամ lighttpd, կարգավորում ենք այն ըստ ուղեցույցների և մոռանում դրա մասին: Եթե ինչ-որ բան փոխելու կարիք ունենք, մենք վերաբեռնում ենք և նորից մոռանում:
Ամեն ինչ փոխվում է, երբ դուք վերամշակում եք մեծ ծավալի երթևեկություն, գնահատում եք հարցումների օրինականությունը, սեղմում և պահում եք օգտվողի բովանդակությունը և միևնույն ժամանակ փոխում եք պարամետրերը վայրկյանում մի քանի անգամ: Օգտագործողը ցանկանում է արդյունքը տեսնել բոլոր արտաքին հանգույցների վրա՝ իր անձնական հաշվի կարգավորումները փոխելուց անմիջապես հետո: Օգտագործողը կարող է նաև API-ի միջոցով ներբեռնել մի քանի հազար (և երբեմն տասնյակ հազարավոր) տիրույթներ՝ տրաֆիկի մշակման անհատական պարամետրերով: Այս ամենը պետք է անմիջապես գործի նաև Ամերիկայում, և Եվրոպայում և Ասիայում. խնդիրն ամենաչնչինը չէ, հաշվի առնելով, որ միայն Մոսկվայում կան մի քանի ֆիզիկապես առանձնացված ֆիլտրման հանգույցներ:
Ինչու՞ կան բազմաթիվ խոշոր հուսալի հանգույցներ ամբողջ աշխարհում:
-
Հաճախորդների տրաֆիկի սպասարկման որակը. ԱՄՆ-ից ստացված հարցումները պետք է մշակվեն ԱՄՆ-ում (ներառյալ հարձակումների, վերլուծության և այլ անոմալիաների համար) և չտեղափոխվեն Մոսկվա կամ Եվրոպա՝ անկանխատեսելիորեն մեծացնելով մշակման հետաձգումը:
-
Հարձակման երթևեկը պետք է տեղայնացված լինի. տարանցիկ օպերատորները կարող են նսեմանալ հարձակումների ժամանակ, որոնց ծավալը հաճախ գերազանցում է 1Tbps-ը: Հարձակման երթևեկությունը տրանսատլանտյան կամ տրանսասիական կապերով տեղափոխելը լավ գաղափար չէ: Մենք իրական դեպքեր ունեինք, երբ Tier-1 օպերատորներն ասում էին. «Հարձակումների այն ծավալը, որը դուք ստանում եք, վտանգավոր է մեզ համար»: Այդ իսկ պատճառով մենք ընդունում ենք մուտքային հոսքերը հնարավորինս մոտ իրենց աղբյուրներին:
-
Ծառայության շարունակականության խիստ պահանջներ. մաքրման կենտրոնները չպետք է կախված լինեն ոչ միմյանցից, ոչ էլ մեր արագ փոփոխվող աշխարհում տեղի ունեցող իրադարձություններից: Մեկ շաբաթով հոսանքազրկե՞լ եք MMTS-11-ի բոլոր 9 հարկերը: - ոչ մի խնդիր. Ոչ մի հաճախորդ, ով չունի ֆիզիկական կապ տվյալ վայրում, չի տուժի, և վեբ ծառայությունները ոչ մի դեպքում չեն տուժի:
Ինչպե՞ս կառավարել այս ամենը։
Ծառայության կազմաձևերը պետք է հնարավորինս արագ բաշխվեն բոլոր առջևի հանգույցներին (իդեալականորեն անմիջապես): Դուք չեք կարող պարզապես վերցնել և վերակառուցել տեքստի կոնֆիգուրացիաները և վերագործարկել դևերը ամեն փոփոխության դեպքում. նույն nginx-ը շարունակում է գործընթացները փակել (աշխատողի անջատումը) ևս մի քանի րոպե (կամ գուցե ժամեր, եթե կան երկար վեբ-սեսիաներ):
Nginx կոնֆիգուրացիան վերաբեռնելիս հետևյալ պատկերը միանգամայն նորմալ է.
Հիշողության օգտագործման վերաբերյալ.
Հին աշխատողները ուտում են հիշողությունը, ներառյալ հիշողությունը, որը գծայինորեն կախված չէ կապերի քանակից, սա նորմալ է: Երբ հաճախորդի կապերը փակվեն, այս հիշողությունը կազատվի:
Ինչու՞ սա խնդիր չէր, երբ nginx-ը նոր էր սկսում: Չկար ոչ HTTP/2, ոչ WebSocket, ոչ մի զանգվածային երկարատև կապեր: Մեր վեբ տրաֆիկի 70%-ը HTTP/2 է, ինչը նշանակում է շատ երկար կապեր:
Լուծումը պարզ է. մի օգտագործեք nginx-ը, մի կառավարեք ճակատները՝ հիմնված տեքստային ֆայլերի վրա և, իհարկե, մի ուղարկեք zipped տեքստի կոնֆիգուրացիաներ անդրխաղաղօվկիանոսյան ալիքներով: Ալիքներն, իհարկե, երաշխավորված են և վերապահված, բայց դա նրանց չի դարձնում պակաս անդրմայրցամաքային:
Մենք ունենք մեր սեփական առջևի սերվեր-բալանսը, որի ներքին մասերի մասին կխոսեմ հաջորդ հոդվածներում։ Հիմնական բանը, որ նա կարող է անել, վայրկյանում հազարավոր կոնֆիգուրացիայի փոփոխություններ կիրառելն է, առանց վերագործարկման, վերբեռնումների, հիշողության սպառման կտրուկ ավելացման և այդ ամենի: Սա շատ նման է Hot Code Reload-ին, օրինակ՝ Erlang-ում: Տվյալները պահվում են աշխարհաբաշխված բանալի-արժեքի տվյալների բազայում և անմիջապես ընթերցվում են առջևի ակտուատորների կողմից: Նրանք. Դուք վերբեռնում եք SSL վկայագիրը Մոսկվայի վեբ ինտերֆեյսի կամ API-ի միջոցով, և մի քանի վայրկյանից այն պատրաստ է գնալ Լոս Անջելեսի մեր մաքրման կենտրոն: Եթե հանկարծ համաշխարհային պատերազմ սկսվի, և ինտերնետը անհետանա ամբողջ աշխարհում, մեր հանգույցները կշարունակեն աշխատել ինքնուրույն և վերանորոգել ուղեղի պառակտումը հենց որ նվիրված ալիքներից մեկը Լոս Անջելես-Ամստերդամ-Մոսկվա, Մոսկվա-Ամստերդամ-Հոնկոնգ- Լոս-Լոսը հասանելի է դառնում Անջելեսում կամ GRE կրկնօրինակումներից առնվազն մեկը:
Այս նույն մեխանիզմը մեզ թույլ է տալիս ակնթարթորեն թողարկել և թարմացնել Let's Encrypt վկայականները: Շատ պարզ այն աշխատում է այսպես.
-
Հենց որ մենք տեսնում ենք առնվազն մեկ HTTPS հարցում մեր հաճախորդի տիրույթի համար առանց վկայագրի (կամ ժամկետանց վկայականով), արտաքին հանգույցը, որն ընդունել է հարցումը, հայտնում է այդ մասին ներքին սերտիֆիկացման մարմնին:
-
Եթե օգտատերը չի արգելել Let's Encrypt-ի թողարկումը, սերտիֆիկացման մարմինը ստեղծում է CSR, ստանում է հաստատման նշան LE-ից և ուղարկում այն բոլոր ճակատներին գաղտնագրված ալիքով: Այժմ ցանկացած հանգույց կարող է հաստատել LE-ի վավերացման հարցումը:
-
Մի քանի պահից մենք կստանանք ճիշտ վկայականն ու անձնական բանալին և նույն ձևով կուղարկենք ճակատներ։ Կրկին, առանց դևերի վերագործարկման
-
Ժամկետը լրանալուց 7 օր առաջ սկսվում է վկայականի վերստացման ընթացակարգը
Հենց հիմա մենք իրական ժամանակում պտտում ենք 350 հազար վկայականներ, որոնք լիովին թափանցիկ են օգտատերերի համար:
Շարքի հաջորդ հոդվածներում ես կխոսեմ մեծ վեբ տրաֆիկի իրական ժամանակի մշակման այլ առանձնահատկությունների մասին, օրինակ՝ RTT-ի վերլուծության մասին՝ օգտագործելով թերի տվյալները՝ տարանցիկ հաճախորդների սպասարկման որակը բարելավելու և ընդհանրապես տարանցիկ երթևեկությունը պաշտպանելու մասին: terabit հարձակումներ, երթևեկության տեղեկատվության առաքման և համախմբման, WAF-ի, գրեթե անսահմանափակ CDN-ի և բովանդակության առաքման օպտիմալացման բազմաթիվ մեխանիզմների մասին:
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Ի՞նչ կցանկանայիք իմանալ առաջինը:
-
14,3%Վեբ տրաֆիկի որակի կլաստերավորման և վերլուծության ալգորիթմներ<3
-
33,3%DDoS-Guard7 հավասարակշռողների ինտերիերներ
-
9,5%Տարանցիկ L3/L4 տրաֆիկի պաշտպանություն2
-
0,0%Կայքերի պաշտպանություն տարանցիկ տրաֆիկի վրա0
-
14,3%Վեբ հավելվածի Firewall3
-
28,6%Պաշտպանություն վերլուծությունից և սեղմելուց6
Քվեարկել է 21 օգտատեր։ 6 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com