Burstable EC2 VPN: Standard- eller Unlimited-CPU-krediter?

En liten VPN-gateway klarar ett hastighetstest, känns bra och blir sedan långsammare efter lunchen. Instansen ljög inte under testet; den gjorde av med krediter som den tjänat medan den var oanvänd. Burstable-instanser är byggda just för det, vilket gör ett kort benchmark till en dålig förutsägelse för en hel eftermiddag av överföringar. De två kreditlägena misslyckas också på olika sätt, och valet mellan dem är det verkliga beslutet.

Var hastighetstestet lånade ifrån

En CPU-kredit är en vCPU som körs med full belastning i en minut. En burstable-instans tjänar krediter i sin baslinjetakt och gör av med dem när den överskrider baslinjen. En oanvänd natt bygger upp ett saldo; en hektisk morgon tömmer det.

Därför ser det första testet bra ut. Instansen hade en sparad budget, gjorde av med den på krypteringsarbete och rapporterade en frisk hastighet. Inget i resultatet säger vad som händer när saldot når noll. Benchmarken mätte en burst, och en burst är vad instansen är byggd att leverera. Den mätte aldrig det jämna tillstånd du är på väg att förlita dig på.

Aritmetiken du måste göra

Indata är baslinjeprocenten per vCPU, antalet vCPU:er, det upparbetade saldot och den belastning du förväntar dig. Bara som illustration: ta en hypotetisk instans med två vCPU:er, tio procents baslinje per vCPU, 24 upparbetade krediter och en vCPU fullt upptagen medan den andra är oanvänd. Dessa siffror är deklarerade indata, inte specifikationen för en viss instansstorlek.

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

Under dessa antaganden är budgeten slut på ungefär en halvtimme. Bakgrundsarbete, varierande belastning och instansens egen bokföring flyttar resultatet, och inget av detta förutsäger VPN-genomströmningen. Det som förutsägs är när den varaktiga begränsningen börjar göra sig gällande.

Notera även den andra läsningen: en upptagen vCPU är ungefär hälften av den samlade CPU-kapaciteten i det här exemplet. En måttlig totalprocent kan dölja en mättad kärna, så titta på beteendet per kärna vid sidan av kreditsiffrorna.

Standard och Unlimited: samma nolla, olika betydelse

I Standard-läget begränsar ett uttömt saldo den varaktiga CPU:n mot baslinjen. Instansen fortsätter arbeta, bara långsammare, och taket är förutsägbart. I Unlimited-läget kan instansen fortsätta att dra på överskottskrediter efter att saldot nått noll, och varaktig användning över baslinjen kan ge kostnader enligt tjänstens bokföringsregler.

Så en CPUCreditBalance på noll betyder strypning i det ena läget och möjlig fakturering i det andra. Det är hela jämförelsen, och därför är det vilseledande att läsa mätvärdet utan läget.

Överskott är inte heller en enkel faktura per kredit. Senare drift under baslinjen kan betala av överskottsanvändningen, och andra kostnadsvillkor gäller. Kontrollera det konfigurerade läget och tjänstens aktuella regler i stället för att lita på ett gratispåstående från ett gammalt blogginlägg.

Vad du ska följa under verkligt arbete

Registrera CPUCreditUsage och CPUCreditBalance bredvid överföringens varaktighet och hastighet. Lägg till CPUSurplusCreditBalance och CPUSurplusCreditsCharged i Unlimited. AWS vägledning för övervakning av CPU-krediter förklarar vad var och en rapporterar och hur ofta.

Testa igen med representativ samtidighet och tillräcklig varaktighet för att se trenden, och registrera startsaldot. En oanvänd morgon och en hektisk eftermiddag är inte samma experiment, ens med identiska kommandon.

Gränser som inte är CPU

Nätverksbandbredd har sin egen baslinje och burstbeteende, och gränser för paketfrekvens eller anslutningar kan begränsa före CPU:n. Minne spelar roll när VPN-implementeringen håller tillstånd per anslutning, och en liten instans kan ta slut på det långt innan den tar slut på krediter.

Ett friskt kreditsaldo bevisar därför en sak: CPU-budgeten är inte den aktuella begränsningen. Det säger ingenting om nätverksvägen, och det säger ingenting om vad som händer vid dubbel samtidighet. Följ nätverksmätvärdena i samma fönster som kreditmätvärdena, så att ett fall i genomströmning har en trolig orsak i stället för en teori.

Att välja en baslinje med avsikt

Använd den uppmätta varaktiga arbetsbelastningen för att välja en baslinje, eller acceptera bursting uttryckligen och budgetera för det. Båda svaren är försvarbara när de är nedskrivna; inget av dem är det när det härleds från någon annans lyckade videoström.

Om gatewayen bär last, behandla kreditläget som en del av kapacitetsplanen i stället för en standardinställning du aldrig öppnade. Läget du väljer är felet du kan förutsäga.