VPN EC2 burstable: קרדיטי CPU סטנדרטיים או בלתי מוגבלים?

שער VPN קטן עובר מבחן מהירות, מרגיש טוב, ואז נחלש אחרי הצהריים. המופע לא שיקר במהלך המבחן; הוא בזבז קרדיטים שצבר בזמן שהיה רדום. מופעי burstable מיועדים בדיוק לכך, ולכן מבחן קצר הוא מנבא גרוע לצהריים מלאים בהעברות. שני מצבי הקרדיטים גם נכשלים בדרכים שונות, והבחירה ביניהם היא ההחלטה האמיתית.

מאיפה מבחן המהירות לווה

קרדיט CPU אחד הוא vCPU אחד שרץ בניצול מלא במשך דקה. מופע burstable צובר קרדיטים בקצב קו הבסיס שלו ומבזבז אותם כשהוא עובר את אותו קו. לילה רדום בונה יתרה; בוקר עמוס מנקז אותה.

לכן המבחן הראשון נראה טוב. למופע הייתה יתרה חסכונית, הוא בזבז אותה על עבודת הצפנה ודיווח על קצב בריא. שום דבר בתוצאה לא אומר לכם מה קורה כשהיתרה מגיעה לאפס. המבחן מדד פרץ, ופרץ הוא מה שהמופע אמור לספק. הוא מעולם לא מדד את המצב היציב שאתם עומדים להסתמך עליו.

החשבון שעליכם לעשות

הקלטים הם אחוז קו הבסיס לכל vCPU, מספר ה-vCPU, היתרה המצטברת והעומס שאתם מצפים לו. להמחשה בלבד: קחו מופע היפותטי עם שני vCPU, קו בסיס של עשרה אחוזים לכל vCPU, 24 קרדיטים מצטברים, ו-vCPU אחד עסוק לגמרי כשהשני רדום. המספרים האלה הם קלטים מוצהרים, לא המפרט של גודל מופע מסוים.

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

בהנחות האלה התקציב נגמר בכחצי שעה. עבודת רקע, עומס משתנה והחשבונאות של המופע עצמו מזיזים את התוצאה, ושום דבר מזה לא מנבא את התפוקה של ה-VPN. מה שזה מנבא הוא מתי האילוץ המתמשך יתחיל להפריע.

שימו לב גם לקריאה השנייה: vCPU אחד עסוק הוא בערך מחצית מכושר ה-CPU הכולל בדוגמה הזו. אחוז כולל מתון יכול להסתיר ליבה רוויה, אז הביטו בהתנהגות לכל ליבה לצד מספרי הקרדיטים.

Standard ו-Unlimited: אותו אפס, משמעות אחרת

במצב Standard, יתרה שנגמרה מגבילה את ה-CPU המתמשך לכיוון קו הבסיס. המופע ממשיך לעבוד, רק לאט יותר, והתקרה צפויה. במצב Unlimited המופע יכול להמשיך למשוך מקרדיטים עודפים אחרי שהיתרה מגיעה לאפס, ושימוש מתמשך מעל קו הבסיס עלול ליצור חיובים לפי כללי החשבונאות של השירות.

לכן CPUCreditBalance השווה לאפס פירושו הגבלה במצב אחד וחיוב אפשרי במצב השני. זו כל ההשוואה, ולכן קריאת המדד בלי לקרוא את המצב מטעה.

גם העודף אינו חשבונית פשוטה לכל קרדיט. תפעול מאוחר מתחת לקו הבסיס יכול לקזז את השימוש בעודף, ותנאי חיוב נוספים חלים. בדקו את המצב המוגדר ואת כללי השירות הנוכחיים במקום להסתמך על טענה על שכבה חינמית מפוסט בלוג ישן.

מה לעקוב אחריו בעבודה אמיתית

רשמו CPUCreditUsage ו-CPUCreditBalance לצד משך ההעברה והקצב שלה. ב-Unlimited הוסיפו CPUSurplusCreditBalance ו-CPUSurplusCreditsCharged. מדריך ניטור קרדיטי CPU של AWS מסביר מה כל אחד מהם מדווח ובאיזו תדירות.

בדקו שוב עם מקביליות מייצגת ומשך מספיק כדי לראות את המגמה, ורשמו את יתרת הפתיחה. בוקר רדום וצהריים עמוסים אינם אותו ניסוי, אפילו עם פקודות זהות.

גבולות שאינם CPU

לרוחב הפס של הרשת יש קו בסיס והתנהגות פרץ משלו, ומגבלות קצב מנות או חיבורים יכולות להיקשר לפני ה-CPU. זיכרון חשוב כשמימוש ה-VPN שומר מצב לכל חיבור, ומופע קטן יכול להיגמר ממנו הרבה לפני שהקרדיטים נגמרים.

יתרת קרדיטים בריאה מוכיחה אפוא דבר אחד: תקציב ה-CPU אינו האילוץ הנוכחי. היא לא אומרת דבר על נתיב הרשת, ולא על מה שקורה בכפילות המקביליות. עקבו אחר מדדי הרשת באותו חלון שבו אתם עוקבים אחר מדדי הקרדיטים, כדי שלירידה בתפוקה תהיה סיבה מועמדת במקום תיאוריה.

לבחור קו בסיס בכוונה

השתמשו בעומס המתמשך הנמדד כדי לבחור קו בסיס, או קבלו את הפריצה במפורש ותקצבו אותה. שתי התשובות מוגנות כשהן כתובות; אף אחת מהן אינה מוגנת כשהן נגזרות מהזרמת וידאו מוצלחת של מישהו אחר.

אם השער נושא עומס, התייחסו למצב הקרדיטים כחלק מתוכנית הקיבולת ולא כברירת מחדל שלא פתחתם מעולם. המצב שתבחרו הוא הכשל שתוכלו לחזות.