Burstable EC2 VPN: Standard അല്ലെങ്കിൽ Unlimited CPU ക്രെഡിറ്റുകൾ?

ഒരു ചെറിയ VPN gateway വേഗത പരിശോധനയിൽ വിജയിക്കുന്നു, കുഴപ്പമില്ലെന്ന് തോന്നുന്നു, പിന്നീട് ഉച്ചഭക്ഷണത്തിന് ശേഷം മന്ദഗതിയിലാകുന്നു. പരിശോധനയ്ക്കിടയിൽ instance കള്ളം പറഞ്ഞിട്ടില്ല; അത് നിഷ്ക്രിയമായിരുന്നപ്പോൾ സമ്പാദിച്ച ക്രെഡിറ്റുകൾ ചെലവഴിക്കുകയായിരുന്നു. Burstable instance-കൾ കൃത്യമായി അതിനാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതിനാൽ ചെറിയ benchmark ഒരു ഉച്ചയ്ക്ക് ശേഷമുള്ള കൈമാറ്റങ്ങൾക്ക് മോശം പ്രവചനമാണ്. രണ്ട് ക്രെഡിറ്റ് മോഡുകളും വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു, അവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പാണ് യഥാർത്ഥ തീരുമാനം.

വേഗത പരിശോധന എവിടെ നിന്ന് കടം വാങ്ങി

ഒരു CPU ക്രെഡിറ്റ് എന്നാൽ ഒരു vCPU ഒരു മിനിറ്റ് പൂർണ്ണ ഉപയോഗത്തിൽ പ്രവർത്തിക്കുന്നത്. Burstable instance അതിന്റെ ബേസ്ലൈൻ നിരക്കിൽ ക്രെഡിറ്റുകൾ സമ്പാദിക്കുന്നു, ആ ബേസ്ലൈൻ കവിയുമ്പോൾ അവ ചെലവഴിക്കുന്നു. നിഷ്ക്രിയ രാത്രി ബാലൻസ് കെട്ടിപ്പടുക്കുന്നു; തിരക്കുള്ള രാവിലെ അത് വലിച്ചെടുക്കുന്നു.

അതുകൊണ്ടാണ് ആദ്യ പരിശോധന നന്നായി തോന്നുന്നത്. instance-ന് സൂക്ഷിച്ച ബജറ്റ് ഉണ്ടായിരുന്നു, അത് എൻക്രിപ്ഷൻ ജോലിക്ക് ചെലവഴിച്ചു, ആരോഗ്യകരമായ നിരക്ക് റിപ്പോർട്ട് ചെയ്തു. ബാലൻസ് പൂജ്യത്തിലെത്തുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് ഫലത്തിൽ ഒന്നും പറയുന്നില്ല. benchmark ഒരു ബർസ്റ്റ് അളന്നു, ബർസ്റ്റ് എന്നത് instance നൽകാൻ രൂപകൽപ്പന ചെയ്തതാണ്. നിങ്ങൾ ആശ്രയിക്കാൻ പോകുന്ന സ്ഥിരതയുള്ള അവസ്ഥ അത് ഒരിക്കലും അളന്നിട്ടില്ല.

നിങ്ങൾ ചെയ്യേണ്ട ഗണിതം

ഇൻപുട്ടുകൾ ഓരോ vCPU-യ്ക്കുമുള്ള ബേസ്ലൈൻ ശതമാനം, vCPU എണ്ണം, സമാഹരിച്ച ബാലൻസ്, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ലോഡ് എന്നിവയാണ്. വെറും ഉദാഹരണത്തിന്, രണ്ട് vCPU ഉള്ള ഒരു സങ്കൽപ്പ instance എടുക്കുക, ഓരോ 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 ഭാരം വഹിക്കുന്നതാണെങ്കിൽ, ക്രെഡിറ്റ് മോഡിനെ ഒരിക്കലും തുറക്കാത്ത ഡിഫോൾട്ടായി കാണാതെ ശേഷി പദ്ധതിയുടെ ഭാഗമായി കാണുക. നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന മോഡാണ് നിങ്ങൾക്ക് പ്രവചിക്കാനാകുന്ന പരാജയം.