משתמשים או תפוקה? תכנון שרת VPN לעומס אמיתי
מספר החשבונות אינו מתכנן שער; העבודה החופפת עושה זאת. השוו העברות מקבילות, מעבד לכל ליבה ותורים, ואז כתבו את העומס.
עשרה חשבונות לא פעילים עולים פחות מגיבוי לילי אחד שממלא את המנהרה, ומספר משתמשים לא יכול להראות את ההבדל. תכנון שרת VPN הוא השוואה בין שני מספרים: המקביליות שאתם באמת נושאים והמשאב שמתרוקן ראשון. רוב טעויות הקיבולת נולדות מבחירה במספר הראשון ומאי-מדידה של השני. עשו את שניהם, בסדר הזה, והחלטת החומרה מפסיקה להיות ניחוש.
השוו את מספר החשבונות לשעת השיא
מספר החשבונות הוא רישיון וגבול תמיכה; שעת השיא היא עומס. רשמו את העבודות שחופפות בשעה הזו: שיחות, ניהול מרחוק, הורדות גדולות, גיבויים ובקשות של אפליקציות פרטיות שמשאירות אנשים ממתינים. אחר כך סמנו לכל פריט אם הוא חוצה את השער ובאיזה כיוון. שיחות הן סימטריות ורגישות להשהיה, בעוד שגיבוי הוא כיוון אחד וסובל התחלה איטית, ולכן הן מעמיסות על חלקים שונים של המסלול.
הכיוון קובע איזה קישור חשוב. קישור ביתי כלפי מעלה הוא לעתים רחוקות סימטרי, וסניף שמוריד קבצים כל היום מגיע לגבול ההורדה שלו הרבה לפני שהשער מתחיל להזיע. כתבו את הכיוון ואת היקף המנהרה ליד כל פריט, כי שער שנושא רק יעדים פרטיים ושער שנושא את כל תעבורת האינטרנט הם שני בעיות תכנון שונות.
הוסיפו עומס רקע כשורה משלו: עדכוני לקוחות, טלמטריה וכל מה שהמארח עושה מלבד העברה. את הבתים האלה קל לשכוח, ואותו ממשק סופר אותם.
מצאו את המשאב שמתרוקן לפני הקישור
הקישור הוא רק מועמד אחד. עבודת ההצפנה של מנהרה אחת יכולה לתפוס ליבה אחת בזמן שהממשק יושב חצי ריק, ותור מלא יכול להפוך שיחות לבלתי שמישות בתפוקה שנראית בינונית בגרף. יעד שנמצא מרחק מסלול איטי אחד יכול להיראות גם כחולשת שער מכיסא הלקוח. שלוש תצפיות מפרידות בין המקרים האלה, ואף אחת מהן לא צריכה מבחן פרץ.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
מדדו עם העברה שמותר לכם להריץ, והוסיפו את העבודה המקבילה בצעדים ולא בבת אחת. קראו את הקצב היציב ואת התגובה האינטראקטיבית יחד, כי מבחן שיא בלבד מסתיר הפעלה שהפכה לבלתי שמישה. שער שעובר את התפוקה המרבית שלו בזמן שהשיחות מתפרקות לא עבר את המבחן.
אחר כך חזרו על הריצה כשהעומסים האופציונליים עצורים. גבול שזז כשהגיבוי נעצר מעולם לא היה הגבול של השער.
הפכו את ההשוואה למספר שאפשר להגן עליו
בחרו את המשאב שהתרוקן ובטאו את הדרישה ביחידות שלו: ליבות בניצול יעד בשעת השיא, סיביות לשנייה בכל כיוון, או הפעלות מקבילות תחת גבול השהיה. השאירו מקום לעדכונים, לאבחון ולשחזור, כי שרת שיושב על התקרה הנמדדת שלו לא השאיר דבר לעבודה שמחזיקה אותו פועל. אחר כך כתבו את המספרים לצד התצורה שהפיקה אותם, כולל מספר הלקוחות והמבחן שבו השתמשתם.
מספר משתמשים לליבה הוא המספר הכי פחות נייד בתרגיל הזה, כי הוא מניח תמהיל פרוטוקולים ופרופיל מכשירים שהאתר הבא לא חולק. שמרו את המדידה וזרקו את הנוסחה. כשמישהו מבקש קיבולת לעוד חמישים משתמשים, התשובה הכנה היא פרופיל שעת השיא של אותם חמישים, לא כפל.
רשמו את זמן התגובה וגם את התפוקה. קיבולת שמשמרת רק העברה בכמות אינה קיבולת לאנשים בשיחות, והסקירה הבאה תשאל על ההבדל.
בחרו בין הרחבה כלפי מעלה לבין פיצול התפקיד
כשהגבול הנמדד הוא ליבה אחת, ייתכן שליבות נוספות באותה מהירות לא יעזרו; ליבה מהירה יותר או מודל עובדים אחר יכול. כשהגבול הוא מעבד כולל, מופע גדול יותר הוא הפתרון הישיר. כשהגבול הוא קישור הגישה, שום שינוי שרת לא עוזר וההשוואה נגמרת אצל הספק. פיצול תפקידי האינטרנט וה-VPN למארחים נפרדים קונה בידוד במחיר משטח ניהול שני.
השוו את האפשרויות האלה למספר שנרשם ולא זו לזו. שינוי שמכפיל משאב שלא היה המגבלה הוא עלות בלי תועלת, והרשומה היא מה שמאפשר לכם לומר זאת בלי ויכוח. מדדו שוב אחרי השינוי עם אותו עומס, אחרת החלפתם ניחוש בניחוש אחר.