Ինչպես ենք փորձարկում DNS, DHCP և AAA. սառը քեշ, renew փոթորիկ

DNS սերվերի բնութագրում վայրկյանում հարցումների թիվը չափված է անունների կարճ ցուցակով, որոնք բոլորը քեշում են։ DHCP-ն գնահատում են մեկ առ մեկ եկող հաճախորդներով, RADIUS-ը՝ մուտքի մեկ մեթոդով և առանց accounting-ի։ Արտադրական ցանցում հաճախորդները հարցնում են անուններ, որոնք երբեք քեշում չեն եղել, հոսանքազրկումից հետո ամբողջ կայքը վերադառնում է նույն րոպեին, իսկ accounting-ը գալիս է յուրաքանչյուր սեսիայից, մինչ օգտատերերը մուտք են գործում։ Մենք չափում ենք, թե ինչ արագություն է պահում յուրաքանչյուր սերվեր Ձեր latency-ի շեմով, և որքան ժամանակ է նրան պետք վերականգնվելու համար, երբ բոլորը գալիս են միասին։

Ստենդը

Սերվերը տեղադրվում է CloudLAB ստենդում որպես appliance կամ աշխատում է որպես VM մեր հոսթերի վրա կամ Ձեր tenant-ում՝ արտադրական կոնֆիգուրացիայով. զոնաներ և forwarder-ներ, DHCP scope-եր և failover զույգ, RADIUS քաղաքականություններ և օգտատերերի կատալոգի թեստային պատճեն։ Գեներատորը խաղում է հաճախորդների դերը։ Resolver-ի համար այն ուղարկում է Ձեր հարցումների խառնուրդը լոգերի նմուշից (A և AAAA, MX, TXT, միանվագ անուններ, NXDOMAIN) և էմուլյացնում է նրա հետևի authoritative սերվերները իրական upstream-ի ուշացումով։ DHCP-ի համար այն խաղում է սեփական MAC հասցեներով հաճախորդներ relay-ների հետևում՝ option 82-ով, v4 և v6 կողք կողքի։ RADIUS-ի համար այն խաղում է NAS-ի դերը. Wi-Fi մուտքի կետեր 802.1X-ով, VPN դարպասներ, լայնաշերտ edge, յուրաքանչյուրն իր մեթոդներով և accounting-ի ինտերվալով։

Յուրաքանչյուր հարցում չափվում է ուղարկումից մինչև պատասխան, ուստի յուրաքանչյուր արագություն ունի իր p50 և p99 latency-ն։ Բեռը աճում է աստիճաններով, ինչպես ստենդի ցանկացած բեռնվածության թեստում, մինչև latency-ն անցնի Ձեր շեմը։

Ինչ ենք ստուգում

• Resolver-ի հզորություն. հարցումներ վայրկյանում Ձեր p99 շեմով, քեշում գտնվածի բաժինը Ձեր լոգերից
• Սառը քեշ. resolver-ը վերագործարկվում է գագաթնակետին, ժամանակը, մինչև p99-ը վերադառնա նորմայի, և upstream հարցումների արագությունը, մինչ քեշը լցվում է
• DNSSEC. նույն խառնուրդը անջատված և միացված վավերացմամբ, դրա արժեքը արագությամբ և latency-ով, կոտրված ստորագրությունների շղթա՝ SERVFAIL պատասխանով
• Authoritative սերվեր. պատասխաններ վայրկյանում Ձեր զոնաների համար, մինչ ընթանում են զոնայի փոխանցումը և դինամիկ թարմացումները
• DHCP. lease-եր վայրկյանում նոր հաճախորդների համար (ամբողջական DORA), renew-ներ վայրկյանում, scope, որում հասցեները վերջացել են
• Renew փոթորիկ. վթարից հետո կայքի բոլոր հաճախորդները գալիս են միասին, ժամանակը, մինչև վերջինը հասցե ստանա, NAK-երի և կրկնակի ուղարկումների հաշվարկով
• RADIUS. մուտքեր վայրկյանում յուրաքանչյուր մեթոդի համար (PAP, CHAP, PEAP, EAP-TLS) p99 latency-ով, զուգահեռ accounting Start, Interim և Stop
• Failover. հիմնական սերվերը կանգնեցվում է փորձարկման ընթացքում, որքան արագ են relay-ներն ու NAS-երը անցնում երկրորդ սերվերին, ճանապարհին կորած հարցումները

Ինչն է սովորաբար խափանվում

Սառը քեշը։ Տիպիկ նախագծում լայնաշերտ ցանցի resolver-ը պահում է իր գագաթնակետը 5 մվ-ից ցածր p99-ով, քանի դեռ քեշը տաք է։ Գագաթնակետին վերագործարկվելուց հետո այն յուրաքանչյուր բացթողում ուղարկում է upstream, հասնում է միաժամանակյա ռեկուրսիվ հարցումների սահմանին և սկսում է գցել։ Հաճախորդները մեկ վայրկյան անց կրկնում են հարցումը, բեռը կրկնապատկվում է, և p99-ը մնում է 1 վ-ից բարձր մոտ 3 րոպե։ Ռեկուրսիայի ավելի բարձր սահմանը և մեկնարկին պահված dump-ից բեռնված քեշը այդ ժամանակը կրճատեցին մինչև 30 վ։

Renew փոթորիկը։ DHCP սերվերն ընտրում են lease-երի այն արագությամբ, որը չափված է հանգիստ ստենդում։ Հոսանքազրկումից հետո մեկ կայքի 20 000 հաճախորդ վերադառնում են միասին։ Սերվերը յուրաքանչյուր lease գրում է սկավառակին և պատասխանելուց առաջ սպասում է failover գործընկերոջ հաստատմանը, վայրկյանում մոտ 300 lease-ի դեպքում հերթը աճում է, հաճախորդները timeout են ստանում և կրկնում հարցումը, և վերջինը հասցե է ստանում 7 րոպե անց։

Accounting, որը խեղդում է մուտքերը։ 50 000 սեսիան 5 րոպե interim ինտերվալով տալիս է վայրկյանում մոտ 170 accounting փաթեթ դեռ առաջին մուտքից առաջ։ Accounting-ի տվյալների բազան դանդաղեց, RADIUS-ի worker-ները սպասում էին դրան, մուտքի latency-ն անցավ NAS-ի 3 վ timeout-ը, և NAS-ը բոլորին տեղափոխեց պահուստային սերվերին, որն օգտագործում էր նույն բազան։ Օգնեցին accounting-ի և մուտքերի առանձին worker խմբերը, իսկ նույն RADIUS-ը բաժանորդային edge-ի կողմից նկարագրված է BNG-ի մասին գրառման մեջ։

Ինչ կա հաշվետվության մեջ

Յուրաքանչյուր սերվերի համար այն արագությունը, որը նա պահում է Ձեր latency-ի շեմով, p50-ով և p99-ով։ Latency-ն ժամանակի ընթացքում յուրաքանչյուր վերագործարկման, փոթորկի և failover-ի միջով՝ վերականգնման ժամանակով և կորած հարցումներով։ Resolver-ների համար քեշում գտնվածի բաժինը, upstream արագությունը և DNSSEC-ի արժեքը։ Հաճախորդների պրոֆիլը, հարցումների խառնուրդը և սերվերի կոնֆիգուրացիան, որպեսզի նույն փոթորիկը կրկնվի հաջորդ թողարկման կամ մրցակից սերվերի վրա։

Որտեղից սկսել

Ուղարկեք մեզ սերվերների ցանկը, հարցումների լոգերից մի նմուշ և հաճախորդների թիվը յուրաքանչյուր կայքում։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ կետերը, ստենդի սխեման և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ վենդորին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։