שיקול דעת לוגי בבעיות רשת

מקרה קלאסי 1

רבים מהמקצוענים בתחום התוכנה חסרים ידע מעמיק בהיגיון של TCP/IP, מה שמוביל לעיתים קרובות לזיהוי שגוי של בעיות כבעיות מסתוריות. חלקם מתייאשים מהמורכבות של ספרות הרשת של TCP/IP, בעוד אחרים מטעים על ידי פרטים מבלבלים ב-Wireshark. לדוגמה, DBA המתמודד עם בעיות ביצועים עשוי לפרש שגוי את נתוני לכידת מנות ב-Wireshark, ומסיק בטעות שהחזרות TCP הן הסיבה.

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

בזמן ניתוח מנות רשת, מידע על חותמת זמן הוא קריטי להיגיון לוגי מדויק. הפרש זמן בטווח המיקרו-שניות בין שתי מנות כפולות מציע או החזרת פסק זמן או לכידת מנות כפולות. בסביבת LAN טיפוסית עם זמן סיבוב (RTT) של כ-100 מיקרו-שניות, שבה TCP החזרות דורשות לפחות RTT אחד, החזרה המתרחשת רק 1/100 מה-RTT סביר יותר להעיד על לכידת מנות כפולות ולא על החזרת פסק זמן אמיתית.

מקרה קלאסי 2

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

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

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

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

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

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

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

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

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

ביום הרביעי, הבעיה לא הופיעה שוב.

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

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

מתוכן התפיסה של המנות למעלה (נתפס מהשרת), נראה שהשאילתא SQL נשלחה בשעה 3 לפנות בוקר. התוכנה התווכחת MySQL לקחה 630 שניות (03:10:30.899249-03:00:00.353157) להחזיר את התגובה SQL ללקוח, מה שמעיד כי התוכנה התווכחת MySQL אכן הגיבה לשאילתא SQL. עם זאת, רק 238 מיקרושניות לאחר מכן (03:10:30.899487-03:10:30.899249), שכבת ה-TCP של השרת קיבלה חבילת איפוס, שהייתה חשודה במהירותה. חשוב לציין כי חבילת האיפוס הזו לא ניתן להניח מיד שהיא来自 הלקוח.

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

אם מניחים שהלקוח שלח איפוס, זה ייתכן להעיד על כך שכבת ה-TCP של הלקוח כבר אינה מזהה את מצב ה-TCP של חיבור זה — מעבר ממצב שנקבע למצב שאינו קיים. שינוי זה במצב ה-TCP היה מודיע ליישום הלקוח על בעיית חיבור, causing the client script to immediately error out. עם זאת, במציאות, הסקריפט של הלקוח עדיין מחכה שהתגובה תחזור. לכן, ההנחה שהלקוח שלח איפוס אינה נכונה — הלקוח לא שלח איפוס. החיבור של הלקוח עדיין פעיל, אך בצד השרת, החיבור המתאים הושבת על ידי האיפוס.

אז מי שלח את האיפוס? החשוד הראשי הוא סביבת הענן של אמזון. בהתבסס על ניתוח לכידת חבילות זה, פעולות ה-DBA שאלו את שירות הלקוחות של אמזון וקיבלו את המידע הבא:

תגובה של שירות הלקוחות מתיישבת עם תוצאות הניתוח, מה שמעיד על כך שה-ELB של אמזון (Elastic Load Balancer, דומה ל-LVS) סיים בכוח את מושב ה-TCP. לפי משובם, אם תגובה חורגת מהמגבלה של 350 שניות (כפי שנצפה בתפיסת החבילות כ-630 שניות), מכשיר ה-ELB של אמזון שולח ריסט לגורם המגיב (במקרה זה, השרת). הסקריפטים של הלקוח שהופעלו על ידי המפתחים לא קיבלו את הריסט והניחו בטעות שהחיבור לשרת עדיין פעיל. המלצות רשמיות לבעיות מסוג זה כוללות שימוש במנגנוני TCP keepalive כדי להקל על בעיות אלו.

עם התגובה הרשמית שהתקבלה, הבעיה נחשבה לפתרונה המלא.

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