עומס שרת VPN מוסבר: משתמשים, CPU או קישור עולה?
ציון עומס נמוך יכול לומר משתמשים בטלים, CPU פנוי או קישור עולה רחב. קראו loadavg, מוני ממשק וקובץ מצב לפני שאתם קוראים לזה מהיר.
שער בעומס 0.4 עדיין יכול לזחול עבור כל משתמש שמאחוריו. העומס הממוצע סופר משימות שניתנות להרצה או שנתקעו בשינה בלתי ניתנת להפסקה, ובמארח בעל ארבעה ליבות מספיק תהליך רווי אחד כדי לדחוף אותו לעבר 1.0 בזמן ששלוש ליבות יושבות בטלות. לקרוא את המספר הזה כמרווח פנוי היא הטעות הנפוצה ביותר בבחירת נקודת קצה. מה שבאמת מגביל מנהרה הוא בדרך כלל אחד מארבעה דברים: ליבה עמוסה אחת, הקישור העולה, התור שלפניו או מדיניות לכל הפעלה שאיש לא תיעד.
העומס הממוצע סופר משימות, לא תפוקה
הליבה דוגמת את תור ההרצה ואת מספר המשימות שממתינות לקלט ופלט, ואז מחליקה את שניהם על פני דקה, חמש וחמש עשרה דקות. שום דבר בהגדרה הזו לא מזכיר בתים, מנות או מנהרות. מארח שאחסון שלו תקוע יכול לדווח על עומס גבוה כמעט בלי תעבורה, ומארח שדוחף גיגה-ביט דרך נתיב נתונים של הליבה יכול לדווח על עומס נוח.
לכן קישור בין עומס לביצועי מנהרה דורש מבט לכל ליבה. אם ליבה אחת רוויה, האחוז המצטבר בלוח המחוונים עדיין ייראה טוב:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20הפקודה השלישית היא החשובה ביותר במארחי VPN. עיבוד מנות במרחב המשתמש ב-OpenVPN 2.x הוא ברובו סדרתי לכל תהליך, ולכן חוט עמוס אחד יכול להפוך לתקרה בזמן שלוח המחוונים מדווח על שפע קיבולת פנויה. אם חוט אחד מחזיק את רוב הליבה בתקופה האיטית שלכם, המארח אינו חסר משאבים בכללותו; הוא מוגבל במימד שבמקרה חשוב.
שימו לב גם לתזמון. ממוצעים של חמש עשרה דקות מסתירים את ההתפרצות שהרסה שיחה, ולכן צילום מסך שצולם אחרי התלונה הוא ראיה חלשה. דגמו בזמן הבעיה, ושמרו את חותמת הזמן עם הפלט.
הקישור העולה והתור שלפניו
מוני הממשק עונים על שאלת רוחב הפס שספרות ה-CPU לא יכולות. הם גם מפרידים בין קיבולת לאובדן, ואלה כשלים שונים עם תיקונים שונים:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitקישור שקרוב לקצב שהוקצה לו במהלך הבדיקה הוא ההסבר, ושום כמות של CPU פנוי לא משנה זאת. שורת ה-qdisc מוסיפה את הפרט שחשוב לתעבורה אינטראקטיבית: הצטברות ונשירה מספרות לכם אם מנות ממתינות בתור לפני שהן יוצאות. תור שמתמלא תחת העלאה מאסיבית יוצר בדיוק את הסימפטום שאנשים מייחסים לשרת המרוחק, כלומר שיחות איטיות על חיבור שעדיין מציג תוצאות טובות במדידות.
מוני שליחה חוזרת תופסים את המקרה שבו מנות יוצאות אך לעולם לא מגיעות נקי. אם השליחות החוזרות עולות בחלון האיטי והממשק רחוק מאוד מקיבולת, הבעיה בנתיב ולא במארח, ומעבר לנקודת קצה אחרת באותה עיר לא יעזור.
מספרי הפעלות מתארים ביקוש, לא מרווח
כל מדריך ציבורי מציג מספר כלשהו של משתמשים מחוברים, וכמעט אף אחד מהם לא אומר לכם מה המשתמשים האלה עושים. עשרים הפעלות שעושות עבודה אינטראקטיבית וארבע הפעלות שמושכות קבצים גדולים יוצרות עומסים שונים מאוד על אותו חומרה. הדפוס השני בלתי נראה במספר משתמשים, והוא זה שהורס ערב שלם. לכן מספר הפעלות נקרא היטב כרמז לביקוש, ולעולם לא כהצהרה על קיבולת פנויה.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
במארח שאתם שולטים בו, קובץ המצב נותן את המימד החסר. OpenVPN כותב תמונת מצב תקופתית הכוללת מוני בתים לכל לקוח, וזה מספיק כדי לראות אם הפעלה אחת אחראית לכל הקישור העולה:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusשתי דגימות בהפרש של עשר שניות הופכות את המונים המצטברים לקצב לכל לקוח. זו המדידה שמספר משתמשים עומד במקומה, וכך גם תגלו שלקוח אחד שהוגדר לא נכון מרווה את הקישור כל לילה באותה שעה.
מגבלות לכל הפעלה מסתתרות במדיניות
שרת יכול להיות בטל ובכל זאת לסרב לתת לכם רוחב פס. מגבלות קצב, תקרות רוחב פס לכל לקוח ועיצוב תעבורה מוחלים לעתים קרובות לפי שם משותף או לפי מאגר, ולכן שני משתמשים על אותו שער יכולים לקבל תוצאות שונות מאוד. המנגנון אינו עדין, אבל הוא בלתי נראה מבחוץ מפני שהמנהרה עולה כרגיל בשני המקרים.
חפשו עיצוב בממשק המנהרה ולא בממשק הפיזי. בדקו אם המגבלה עוקבת אחרי המשתמש, התעודה או מאגר הכתובות. אם חשבון הבדיקה שלכם נוחת במאגר ללא תקרה, תסיקו שהשרת תקין והמשתמש המתלונן טועה. מסקנה כזו גרועה מאי-מסקנה, כי היא סוגרת את הפנייה.
השוו שתי נקודות קצה במשימה קבועה אחת
הניסוי בצד הלקוח עדיין שווה הרצה, אבל רק אם המשתנים מקובעים. השתמשו באותו מכשיר, באותה רשת גישה, באותו פרוטוקול ובאותו קובץ יעד, ואז חזרו על כך מול נקודת קצה שנייה במרחק דומה. כל דבר שמשתנה בין ריצות, כולל שעת היום, מזהם את התוצאה.
תעדו כשלים בקפידה כמו הצלחות. סדרה שבה שלוש נקודות קצה עובדות ואחת נגמרת בזמן קצוב היא אינפורמטיבית יותר מארבעה מספרי מהירות, כי היא מצביעה על בעיית נתיב או מדיניות ולא על בעיית קיבולת. הריצו כל מקרה לפחות פעמיים; דגימה איטית אחת לא מוכיחה דבר ברשת משותפת.
לבסוף, שמרו את המספרים שאספתם יחד עם הטענה שהם תומכים בה. "נקודת הקצה הזו השלימה את ההעברה באותו חלון שבו האחרת נתקעה" היא הגנה סבירה, ואילו "נקודת הקצה הזו מהירה יותר" מזמינה ויכוח שאי אפשר לנצח בציון מדף הבית. המדריך של OpenVPN 2.6 מתעד את קובץ המצב ואת אפשרויות העיצוב אם אתם צריכים את ההוראות המדויקות לצד המארח.