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 throughput ಅನ್ನು ಮುನ್ಸೂಚಿಸುವುದಿಲ್ಲ. ಅದು ಮುನ್ಸೂಚಿಸುವುದು ಸ್ಥಿರ ನಿರ್ಬಂಧ ಯಾವಾಗ ಬಾಧಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬುದನ್ನು.

ಎರಡನೇ ಓದುವಿಕೆಯನ್ನೂ ಗಮನಿಸಿ: ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಒಂದು ಕಾರ್ಯನಿರತ vCPU ಒಟ್ಟು CPU ಸಾಮರ್ಥ್ಯದ ಸುಮಾರು ಅರ್ಧದಷ್ಟು. ಮಧ್ಯಮ ಒಟ್ಟು ಶೇಕಡಾವಾರು ಸ್ಯಾಚುರೇಟೆಡ್ ಕೋರ್ ಅನ್ನು ಮರೆಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಕ್ರೆಡಿಟ್ ಸಂಖ್ಯೆಗಳ ಜೊತೆಗೆ ಪ್ರತಿ ಕೋರ್ ನಡವಳಿಕೆಯನ್ನು ನೋಡಿ.

Standard ಮತ್ತು Unlimited: ಅದೇ ಶೂನ್ಯ, ಬೇರೆ ಅರ್ಥ

Standard ಮೋಡ್ನಲ್ಲಿ, ಖಾಲಿಯಾದ ಬ್ಯಾಲೆನ್ಸ್ ಸ್ಥಿರ CPU ಅನ್ನು ಬೇಸ್ಲೈನ್ ಕಡೆಗೆ ನಿರ್ಬಂಧಿಸುತ್ತದೆ. instance ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತದೆ, ಬರೀ ನಿಧಾನವಾಗಿ, ಮತ್ತು ಮೇಲ್ಛಾವಣಿ ಊಹಿಸಬಹುದಾದದ್ದು. Unlimited ಮೋಡ್ನಲ್ಲಿ, ಬ್ಯಾಲೆನ್ಸ್ ಶೂನ್ಯ ತಲುಪಿದ ನಂತರವೂ instance ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ಗಳಿಂದ ಎಳೆಯುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು, ಮತ್ತು ಬೇಸ್ಲೈನ್ನ ಮೇಲಿನ ಸ್ಥಿರ ಬಳಕೆ ಸೇವೆಯ ಲೆಕ್ಕಾಚಾರ ನಿಯಮಗಳ ಅಡಿಯಲ್ಲಿ ಶುಲ್ಕಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ಆದ್ದರಿಂದ CPUCreditBalance ಶೂನ್ಯವೆಂದರೆ ಒಂದು ಮೋಡ್ನಲ್ಲಿ ನಿಯಂತ್ರಣ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಸಂಭಾವ್ಯ ಬಿಲ್ಲಿಂಗ್. ಅದೇ ಸಂಪೂರ್ಣ ಹೋಲಿಕೆ, ಮತ್ತು ಮೋಡ್ ಓದದೆ ಮೆಟ್ರಿಕ್ ಓದುವುದು ದಾರಿತಪ್ಪಿಸುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ.

ಹೆಚ್ಚುವರಿಯೂ ಪ್ರತಿ ಕ್ರೆಡಿಟ್ಗೆ ಸರಳ ಇನ್ವಾಯ್ಸ್ ಅಲ್ಲ. ಬೇಸ್ಲೈನ್ನ ಕೆಳಗಿನ ನಂತರದ ಕಾರ್ಯಾಚರಣೆ ಹೆಚ್ಚುವರಿ ಬಳಕೆಯನ್ನು ತೀರಿಸಬಹುದು, ಮತ್ತು ಇತರ ಶುಲ್ಕ ಷರತ್ತುಗಳು ಅನ್ವಯಿಸುತ್ತವೆ. ಹಳೆಯ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ನಿಂದ ಉಚಿತ ಶ್ರೇಣಿಯ ಹೇಳಿಕೆಯನ್ನು ಅವಲಂಬಿಸುವ ಬದಲು ಸಂರಚಿತ ಮೋಡ್ ಮತ್ತು ಪ್ರಸ್ತುತ ಸೇವಾ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ನಿಜವಾದ ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ಏನನ್ನು ಗಮನಿಸಬೇಕು

ವರ್ಗಾವಣೆಯ ಅವಧಿ ಮತ್ತು ದರದ ಪಕ್ಕದಲ್ಲಿ CPUCreditUsage ಮತ್ತು CPUCreditBalance ಅನ್ನು ದಾಖಲಿಸಿ. Unlimited ನಲ್ಲಿ, CPUSurplusCreditBalance ಮತ್ತು CPUSurplusCreditsCharged ಸೇರಿಸಿ. AWS ನ CPU ಕ್ರೆಡಿಟ್ ಮೇಲ್ವಿಚಾರಣಾ ಮಾರ್ಗದರ್ಶಿ ಪ್ರತಿಯೊಂದೂ ಏನನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಬಾರಿ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪ್ರತಿನಿಧಿ ಸಮಕಾಲೀನತೆ ಮತ್ತು ಪ್ರವೃತ್ತಿಯನ್ನು ನೋಡಲು ಸಾಕಷ್ಟು ಅವಧಿಯೊಂದಿಗೆ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಪ್ರಾರಂಭದ ಬ್ಯಾಲೆನ್ಸ್ ಅನ್ನು ದಾಖಲಿಸಿ. ನಿಷ್ಕ್ರಿಯ ಬೆಳಗ್ಗೆ ಮತ್ತು ಕಾರ್ಯನಿರತ ಮಧ್ಯಾಹ್ನ ಒಂದೇ ಆದೇಶಗಳೊಂದಿಗೂ ಒಂದೇ ಪ್ರಯೋಗವಲ್ಲ.

CPU ಅಲ್ಲದ ಮಿತಿಗಳು

ನೆಟ್ವರ್ಕ್ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ಗೆ ತನ್ನದೇ ಬೇಸ್ಲೈನ್ ಮತ್ತು ಬರ್ಸ್ಟ್ ನಡವಳಿಕೆ ಇದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ದರ ಅಥವಾ ಸಂಪರ್ಕ ಅನುಮತಿಗಳು CPU ಗಿಂತ ಮೊದಲು ಬಿಗಿಯಾಗಬಹುದು. VPN ಅನುಷ್ಠಾನವು ಪ್ರತಿ ಸಂಪರ್ಕದ ಸ್ಥಿತಿಯನ್ನು ಇಟ್ಟುಕೊಂಡಾಗ ಮೆಮೊರಿ ಮುಖ್ಯ, ಮತ್ತು ಸಣ್ಣ instance ಕ್ರೆಡಿಟ್ಗಳಿಗಿಂತ ಬಹಳ ಮೊದಲು ಅದನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು.

ಆದ್ದರಿಂದ ಆರೋಗ್ಯಕರ ಕ್ರೆಡಿಟ್ ಬ್ಯಾಲೆನ್ಸ್ ಒಂದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: CPU ಬಜೆಟ್ ಪ್ರಸ್ತುತ ನಿರ್ಬಂಧವಲ್ಲ. ಅದು ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡು ಪಟ್ಟು ಸಮಕಾಲೀನತೆಯಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಕ್ರೆಡಿಟ್ ಮೆಟ್ರಿಕ್ಗಳ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಗಮನಿಸಿ, ಇದರಿಂದ throughput ಕುಸಿತಕ್ಕೆ ಸಿದ್ಧಾಂತವಲ್ಲದೆ ಸಂಭಾವ್ಯ ಕಾರಣ ಇರುತ್ತದೆ.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬೇಸ್ಲೈನ್ ಆಯ್ಕೆ ಮಾಡುವುದು

ಅಳೆದ ಸ್ಥಿರ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಬೇಸ್ಲೈನ್ ಆಯ್ಕೆ ಮಾಡಲು ಬಳಸಿ, ಅಥವಾ ಬರ್ಸ್ಟಿಂಗ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಒಪ್ಪಿಕೊಂಡು ಅದಕ್ಕೆ ಬಜೆಟ್ ಮಾಡಿ. ಎರಡೂ ಉತ್ತರಗಳು ಬರೆದಿಟ್ಟಾಗ ಸಮರ್ಥನೀಯ; ಬೇರೊಬ್ಬರ ಯಶಸ್ವಿ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್ನಿಂದ ಊಹಿಸಿದ್ದು ಸಮರ್ಥನೀಯವಲ್ಲ.

gateway ಭಾರ ಹೊತ್ತರೆ, ಕ್ರೆಡಿಟ್ ಮೋಡ್ ಅನ್ನು ನೀವು ಎಂದೂ ತೆರೆಯದ ಡೀಫಾಲ್ಟ್ ಎಂದಲ್ಲ, ಸಾಮರ್ಥ್ಯ ಯೋಜನೆಯ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಿ. ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಮೋಡ್ ನೀವು ಮುನ್ಸೂಚಿಸಬಹುದಾದ ವೈಫಲ್ಯ.