IP סטטי ב-GCP מול מהירות VPN: שלושה משתנים, בדיקה אחת

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

מה כתובת שמורה באמת קונה

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

אלה סיבות טובות לשמור אחת. אף אחת מהן אינה סיבת תפוקה.

החזיקו שכבה, כתובת ותעבורה כשלושה משתנים

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

שלושה משתנים, שלושה ניסויים נפרדים, אחרת התוצאה היא סיפור ולא מדידה.

תכננו בדיקה שעונה על שאלה אחת

השאירו את ה-VM, הכתובת, מיקום הלקוח, היעד ועומס העבודה קבועים בזמן שאתם משווים פרופילי UDP ו-TCP מאושרים. דרושים גם מאזין שרת לכל תעבורה וגם כללי חומת אש תואמים; עריכת מילת מפתח בלקוח והשארת המאזין ללא שינוי בוחנת רק את הסבלנות שלכם. השתמשו בהעברה ניתנת לחזרה ותעדו כיוון, משך, זרמים בודדים מול מקבילים ואת היחידות, כי MB/s ו-Mb/s נבדלים פי שמונה.

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

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

למה UDP ו-TCP נבדלים מכנית

OpenVPN מעל UDP נושא דטה-גרמים ומשאיר לתעבורה של היישום עצמו לטפל באובדן. מעל TCP, הזרם האמין של המנהרה יושב מתחת לזרם יישום אמין ממילא, כך שסגמנט שאבד עוצר את כל מה שמאחוריו בזמן שהחיבור החיצוני משדר מחדש לפי לוח הזמנים שלו. התנהגות ראש התור הזו היא תכונה של מנהרור TCP בתוך TCP, לא מדיניות של ספק. גם הטיפול ב-MTU וב-MSS שונה בין שני המצבים, מה שמשנה את התנהגות הפיצול באותו נתיב.

ניסוי TCP מהיר יותר מוכיח אפוא ש-TCP היה מהיר יותר באותו יום באותו נתיב, ושום דבר כללי יותר.

כתבו את התוצאה כך שתשרוד ביקורת

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

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