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 დატვირთვის მატარებელია, მოეპყარით კრედიტურ რეჟიმს, როგორც სიმძლავრის გეგმის ნაწილს და არა ნაგულისხმევს, რომელიც არასოდეს გაგიხსნიათ. რეჟიმი, რომელსაც აირჩევთ, არის ის ხარვეზი, რომლის პროგნოზირებაც შეგიძლიათ.