סשן Oracle נפל דרך VPN? בדקו את שכבות ה-keepalive

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

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

איזו זרימה נשקטת

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

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

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

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

האם מדיניות החוסר-פעילות פגה או מגבילה

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

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

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

מתג ה-socket שמאחורי ברירות המחדל של לינוקס

keepalive הוא אופציונלי לכל socket. ברירות המחדל של ה-kernel מתארות כיצד מתנהגות הבדיקות לאחר שה-socket הפעיל את המנגנון, והן אינן מפעילות אותו לחיבורים קיימים. אפליקציה שלעולם אינה מבקשת אותו אינה מקבלת בדיקות, יהיו ערכי sysctl אשר יהיו.

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

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

EXPIRE_TIME הוא הגדרת מסד נתונים, לא תיקון רשת

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

SQLNET.EXPIRE_TIME = 5

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

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

בדקו את המרווח השקט, ואז תכננו התאוששות

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

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

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

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