סימון DSCP או הבטחת QoS של הספק? אף אחד מהם אינו חוזה

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

local match → queue and marking → provider classifier
  → provider treatment → destination

איפה סימון נכון יכול למות בשקט

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

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

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

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

מה המתזמן באמת מחלק

למדיניות מקומית יש סמנטיקה משלה, וזו שגורמת להכי הרבה אי-הבנה היא המילה “remaining”. בפלטפורמות שמתאר מדריך התזמון של IOS XE, bandwidth remaining percent קובע משקל עודף, לא שלב ברצף שבו כל מחלקה לוקחת נתח ממה שהמחלקה הקודמת השאירה. אחוזים שלא הוקצו מתפזרים על פני תורים כשירים שאינם מוגדרים ולא נשמרים למחלקה האחרונה בקובץ.

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

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

המונים אומרים איזה חצי נכשל

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

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

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

כתבו את החוזה במקום אחד

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

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