Burstable EC2 VPN՝ Standard, թե Unlimited CPU կրեդիտներ

Փոքր VPN gateway-ը անցնում է արագության թեստը, իրեն լավ է զգում, հետո ճաշից հետո սկսում է դանդաղել։ Instance-ը թեստի ընթացքում չէր ստում. այն ծախսում էր կրեդիտներ, որոնք վաստակել էր պարապ ժամանակ։ Burstable instance-ները հենց դրա համար են նախագծված, ինչը կարճ benchmark-ը դարձնում է վատ կանխատեսող ամբողջ կեսօրվա փոխանցումների համար։ Երկու կրեդիտային ռեժիմները նաև տարբեր կերպ են ձախողվում, և նրանց միջև ընտրությունը իրական որոշումն է։

Որտեղից արագության թեստը պարտք վերցրեց

Մեկ CPU կրեդիտը մեկ vCPU է, որը աշխատում է լրիվ օգտագործմամբ մեկ րոպե։ Burstable instance-ը կրեդիտներ է վաստակում իր բազային գծի տեմպով և ծախսում դրանք, երբ գերազանցում է այդ բազային գիծը։ Պարապ գիշերը կուտակում է մնացորդ. զբաղված առավոտը քաշում է այն։

Ահա թե ինչու առաջին թեստը լավ է երևում։ Instance-ը ուներ խնայված բյուջե, ծախսեց այն գաղտնագրման աշխատանքի վրա և հաղորդեց առողջ արագություն։ Արդյունքի ոչինչ չի ասում, թե ինչ է լինում, երբ մնացորդը հասնում է զրոյի։ Benchmark-ը չափեց պոռթկում, և պոռթկումն այն է, ինչ instance-ը նախատեսված է տալու։ Այն երբեք չափեց այն կայուն վիճակը, որի վրա դուք պատրաստվում եք հենվել։

Այն թվաբանությունը, որը դուք պետք է անեք

Մուտքային տվյալներն են բազային գծի տոկոսը յուրաքանչյուր vCPU-ի համար, vCPU-ների քանակը, կուտակված մնացորդը և ձեր սպասվող ծանրաբեռնվածությունը։ Միայն պատկերազարդման համար վերցնենք հիպոթետիկ instance՝ երկու vCPU-ով, տասը տոկոս բազային գծով յուրաքանչյուր vCPU-ի համար, 24 կուտակված կրեդիտով, և մեկ vCPU ամբողջությամբ զբաղված, մինչ մյուսը պարապ է։ Այս թվերը հայտարարված մուտքեր են, ոչ թե որևէ կոնկրետ instance-ի չափի ճշգրտում։

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

Այդ ենթադրություններով բյուջեն սպառվում է մոտ կես ժամում։ Ֆոնային աշխատանքը, փոփոխվող ծանրաբեռնվածությունը և instance-ի սեփական հաշվառումը տեղափոխում են արդյունքը, և այս ամենը չի կանխատեսում VPN-ի թողունակությունը։ Այն կանխատեսում է, թե երբ է սկսելու ազդել կայուն սահմանափակումը։

Ուշադրություն դարձրեք նաև երկրորդ ընթերցմանը. այս օրինակում մեկ զբաղված vCPU-ն մոտավորապես CPU-ի ամբողջ հզորության կեսն է։ Չափավոր ընդհանուր տոկոսը կարող է թաքցնել հագեցած միջուկ, ուստի դիտեք միջուկների վարքը կրեդիտների թվերի կողքին։

Standard և Unlimited. նույն զրոն, տարբեր իմաստ

Standard ռեժիմում սպառված մնացորդը կայուն CPU-ն սեղմում է դեպի բազային գիծը։ Instance-ը շարունակում է աշխատել, պարզապես ավելի դանդաղ, և առաստաղը կանխատեսելի է։ Unlimited ռեժիմում instance-ը կարող է շարունակել քաշել ավելցուկային կրեդիտներից այն բանից հետո, երբ մնացորդը հասնում է զրոյի, և բազային գծից բարձր կայուն օգտագործումը կարող է գանձումներ առաջացնել ծառայության հաշվառման կանոններով։

Այսպիսով, CPUCreditBalance-ի զրոն նշանակում է սահմանափակում մի ռեժիմում և հնարավոր հաշիվ մյուսում։ Դա է ամբողջ համեմատությունը, և դա է պատճառը, որ ցուցիչը ռեժիմից առանձին կարդալը մոլորեցնող է։

Ավելցուկը նույնպես պարզ մեկ կրեդիտի հաշիվ չէ։ Բազային գծից ցածր հետագա աշխատանքը կարող է մարել ավելցուկային օգտագործումը, և գործում են այլ գանձման պայմաններ։ Ստուգեք կարգավորված ռեժիմը և ծառայության ընթացիկ կանոնները՝ հին բլոգային գրառումից անվճար փաթեթի պնդմանը հենվելու փոխարեն։

Ինչին հետևել իրական աշխատանքի ընթացքում

Գրանցեք CPUCreditUsage-ը և CPUCreditBalance-ը փոխանցման տևողության և արագության կողքին։ Unlimited-ում ավելացրեք CPUSurplusCreditBalance-ը և CPUSurplusCreditsCharged-ը։ AWS-ի CPU կրեդիտների մոնիտորինգի ուղեցույցը բացատրում է, թե ինչ է հաղորդում յուրաքանչյուրը և որքան հաճախ։

Կրկին փորձարկեք ներկայացուցչական զուգահեռականությամբ և բավարար տևողությամբ՝ միտումը տեսնելու համար, և գրանցեք մեկնարկային մնացորդը։ Պարապ առավոտը և զբաղված կեսօրը նույն փորձը չեն, նույնիսկ նույնական հրամաններով։

Սահմանափակումներ, որոնք CPU չեն

Ցանցի թողունակությունն ունի իր բազային գիծը և պոռթկման վարքը, և փաթեթների արագության կամ միացումների թույլտվությունները կարող են սահմանափակել ավելի շուտ, քան CPU-ն։ Հիշողությունը կարևոր է, երբ VPN-ի իրականացումը պահում է վիճակ յուրաքանչյուր միացման համար, և փոքր instance-ը կարող է սպառել այն շատ ավելի վաղ, քան կրեդիտները։

Առողջ կրեդիտային մնացորդը հետևաբար ապացուցում է մեկ բան. CPU-ի բյուջեն ընթացիկ սահմանափակումը չէ։ Այն ոչինչ չի ասում ցանցային ուղու մասին և ոչինչ չի ասում, թե ինչ է լինում կրկնակի զուգահեռականության դեպքում։ Դիտեք ցանցային ցուցիչները նույն պատուհանում, ինչ կրեդիտային ցուցիչները, որպեսզի թողունակության անկումը ունենա հավանական պատճառ, այլ ոչ թե տեսություն։

Բազային գիծ ընտրելը գիտակցաբար

Օգտագործեք չափված կայուն ծանրաբեռնվածությունը բազային գիծ ընտրելու համար, կամ բացահայտ ընդունեք պոռթկումը և բյուջե հատկացրեք դրա համար։ Երկու պատասխանն էլ արդարացված է, երբ գրված է. ոչ մեկը արդարացված չէ, երբ եզրակացվում է ուրիշի հաջող տեսահոսքից։

Եթե gateway-ը կրում է բեռ, կրեդիտային ռեժիմը դիտարկեք որպես հզորության պլանի մաս, այլ ոչ թե որպես լռելյայն, որը երբեք չեք բացել։ Ձեր ընտրած ռեժիմը այն խափանումն է, որը դուք կարող եք կանխատեսել։