מאת: יורם אורזך, מנהל טכני בחברת NDI, yoram@ndi.co.il
"הכרזה על שת"פ חדש בין חברת אגינקס תקשורת ומחשוב לבין חברת NDI, לביצוע ניהול ואופטימיזציה של רשתות ארגוניות, כשירות מנוהל לעסקים".
כללי
לכל אחד מאיתנו, מנהל מערכות מידע או מנהל מחשוב, ידועה התופעה של משתמשים המתלוננים על "הרשת שאינה עובדת". תלונות על "ניתוקים", "עבודה איטית", "אפליקציה שלא זזה" ורבות אחרות, מדירות לא מעט שינה מעיננו. מצד שני, כשאנו פונים לפתרון הבעיה, יציעו לנו "בדיקת סניפר", "הקמת מערכת בקרה (במחיר אסטרונומי)" ועוד. סדרת מאמרים זו, שבא אנו פותחים, באה לתת כלים בסיסיים לכל מנהל רשת ומחשוב לאיתור תקלות בארגונו. בהמשך הסדרה יובאו גם מאמרים בנושאי תכנון רשתות.
מה השיטות הקיימות לאיתור תקלות? איך לנטר רשת בצורה יעילה וזולה? איך לקבל אינדיקציה ראשונית היכן הבעיה ברשת? והאם צריך לקרוא למומחה? מטרת מאמר זה הינה לתת סקירה ראשונית של האמצעים הקיימים, שיטות ודרכי בדיקה. במאמרים בהמשך הסדרה, תינתנה סקירות מעמיקות יותר על כל כלי בנפרד, כולל כלי שליטה ובקרה ו- SNMP, נתחי פרוטוקולים (Wireshark), ניטור באמצעות ציודי התקשורת עצמם ועוד.
מה הבעיה?
קודם כל, נבהיר דבר אחד חשוב, שאולי יישמע לרובנו מוזר: הבעיה בד"כ אינה ברשת התקשורת. מניסיוננו אנו יודעים, כי אם ניקח מאה תקלות של ניתוקים, עבודה איטית, או כל תופעת "הרשת לא עובדת" אחרת, בסביבות 50-60% מהבעיות יהיו בעיות אפליקטיביות, 30-40% בעיות מחשוב, ורק בסביבות 10-20% מהבעיות יהיו בעיות תקשורת.
למרות זאת, הרבה מהבעיות הינן בעיות משולבות, בהן האפליקציה לא עובדת בצורה יעילה עם המשאבים של הרשת, קיים חוסר זיכרון או מצוי מעבד איטי בשרת, שגורמות לעומס על הרשת.
הדוגמאות לכך הן רבות. לדוגמא, באחת ממערכות הבחירות המקדימות האחרונות למפלגות, הייתה עבודה איטית מאוד מול שרת הבחירות, באופן שעיכב בצורה משמעותית את ההצבעה. בבדיקת רשת, שנערכה באמצעות נתח פרוטוקולים, התברר כי מערכת ההצבעה (המחשב בעמדת הקלפי) שולחת ומקבלת כ- 60 מנות (Packets) מול השרת עבור כל בוחר שמגיע לקלפי. לכשעצמה, זוהי כמות מידע זניחה, שלא אמורה להשפיע על הרשת. אכן, לפי חישובי רוחב פס שנעשו, היא לא הייתה אמורה להשפיע. הבעיה הייתה, שבאתרים שחוברו במודם סלולארי בטכנולוגיית CDMA1x, ה- Delay (RTT) על הקו היה כ- 300mS, מה שגרם ל- 60 מנות לעבור ברשת ב- 60*300mS, כלומר, 18 שניות באופן תיאורטי, כאשר, הזמן ארך יותר מפי שניים מזה, ומצביעים נתקעו בתורים עקב כך. התקלה תוקנה תוך כדי עבודה, והחל משעות אחה"צ ביום הבחירות, מהירות העבודה שופרה משמעותית. תקלה זו למשל, הינה דוגמא למערכת בסיס נתונים, שתוכננה לעבוד ברשתות קוויות, בהן נבדקה ועבדה בצורה תקינה. אולם, ברשת סלולארית מדור 2.5 השתבשה העבודה לחלוטין.
איך בודקים?
לפני שאנו באים לבדוק רשת תקשורת, מספר מילים על מתודולוגיית הבדיקה. המתודולוגיה שבא אנו משתמשים פשוטה מאוד, ומתבססת על מודל בדיקות, כלים, והבנה מעמיקה של אופן פעולת רשת תקשורת.
מודל הבדיקה:
מודל הבדיקה בו אנו משתמשים, מתבסס על:
1. מודל OSI הישן והטוב.
2. תכנון הגישה לפתרון, תיעוד וניתוח שיטתי ובידוד הבעיה.
כלי הבדיקה:
כלי הבדיקה, מחולקים ל- 6 קטגוריות שונות:
1. כלי CLI סטנדרטיים – Ping, Trace, וכד’.
2. קריאת נתונים מתוך ציודי התקשורת – מתגים, נתבים, FWs וכד’.
3. נתחי פרוטוקולים – Wireshark, Sniffer וכד’.
4. כלי SNMP – לניטור נקודתי ומתמשך – SNMPc, HPOV וכד’.
5. כלים ייעודיים – Netfllow לניתוח תנועה ברמת המשתמש והיישום, Solarwinds כחבילה של כלים הנדסיים וכד’.
6. ציוד בדיקה וסימולציה, לניתוח תקלות ומצבים מורכבים – Spirent, Agilent וכד’.
מודל הבדיקה לפי OSI
במודל OSI, שפורסם כבר לפני למעלה מ- 30 שנה, מתואר המבנה של הרשת בצורת שכבות, שזוהי בדיוק הדרך לאיתור תקלות ברשת.
בבדיקת רשת, נבצע התהליך הבא:
1. בדיקות של הרמה הפיסית – כבלי נחושת, תווך אלחוטי וכד’.
2. בדיקות ברמה 2 –שגיאות ברמת המתגים המקומיים, לולאות, Broadcast storms וכד’.
3. בדיקות ברמה 3 - בעיות ניתוב, כתובות כפולות וכד’.
4. בדיקות ברמה 4 - אופן העבודה בין יישומי קצה, תופעות איטיות ב- TCP, Retransmissions. Duplicate ACKs, Zero Windows וכד’.
5. ברמות הגבוהות, 5 עד 7 - בעיות אפליקטיביות כמו תקלות התחברות ב- VoIP, בעיות ביצועים בבסיסי הנתונים וכד’.
תכנון הגישה לפתרון, תיעוד וניתוח שיטתי ובידוד הבעיה
באיתור תקלות, אנו נדרשים לידע בתקשורת ומערכות, כלי עבודה נכונים, ותהליך עבודה מסודר. תהליך העבודה חייב לכלול מיפוי מדויק של הרשת, כולל תרשימי תנועה (Flows), וכן תיעוד של כל אחת מהפעולות שעשינו, ושאנו עומדים לעשות.
בתמונה אנו רואים את התהליך המסודר לפתרון תקלה. דילוג על אחד שלבים, יכול להכניס אותנו ללולאה שלא נצא ממנה.
1. הגדרת הבעיה – האם הבעיה מתרחשת תמיד או לפעמים? האם בכל היישומים או רק בחלק מהם? כאשר הבעיה מתרחשת ביישום מסוים, האם הדבר קורה תמיד או רק במסכים מסוימים?
2. איסוף העובדות – לאסוף את כל הנתונים בצורה מדויקת, לשרטט את הרשת, לראיין את המשתמשים, וכד’.
3. לשקול את אפשרויות הבדיקה – האם נפעיל מערכת SNMP לניטור ארוך טווח? האם נשתמש ב- Wireshark מול שרת מסוים? האם אנו נדרשים לסימולציה של הבעיה וכד’.
4. יצירת תוכנית עבודה – לכתוב בצורה מסודרת מה אנו הולכים לעשות, מה אנו מצפים לקבל מכל שלב בבדיקה, ומה נעשה עם תוצאה שנקבל.
5. ביצוע הבדיקה ותיעוד מדויק של כל שלב.
6. ניתוח התוצאות, בדיקה האם תפסנו או איתרנו את הבעיה, והמשך לשלב הבא אם לאו.
7. תיעוד מדויק של הבעיה ופתרונה, וזאת כמובן כדי שלא נבצע את אותם כשלים בעתיד.
כלי הבדיקה:
כלי הבדיקה הראשונים שבהם נשתמש הינם כלי המחשב הבסיסיים – Ping, Tracert וכד’. כלים אלו הם הסטטוסקופ, שבו ישתמש רופא טוב כדי לקבל אינדיקציה ראשונית על הבעיה ממנה אנו סובלים.
בכלים אלו נשתמש לקבלת "תחושה" ראשונית של הבעיה ברשת. כך למשל, נוכל באמצעות Tracert לאתר לולאות ניתוב, באמצעות Ping לגלות זמני תגובה לא הגיוניים, באמצעות Arp כתובות כפולות וכד’. אם למשל על קווי WAN, ידוע לנו שצריך להתקבל RTT של mSec בודדים (בד"כ 1 עד 5), ואנו מקבלים במדידות עשרות mSec, נדע ללכת ולבדוק האם הקו עמוס, האם הוא לא תקין, האם קיבלנו רוחב פס נמוך מזה שהובטח לנו, או אם אפילו הקצב של קווי ה- MPLS החדשים שקנינו מיושם ברשת FR שהיא איטית יותר.
כלי בדיקה נוסף, שזמין לנו תמיד, ובתנאי שציוד התקשורת בארגון מנוהל, זה גישה לציוד התקשורת. הגישה יכולה להיות ב- Telnet, גישה ב- HTTP, או תוכנה ייעודית (נורטל JDM וכד’).
באמצעות גישה לציוד התקשורת נוכל לראות נתונים רבים נוספים. כך למשל, נוכל לראות שגיאות על כל ממשקי הציוד, Interface resets שיהיו למשל אינדיקציה לניתוקים, וכן עומס על הציוד עצמו, למשל עומס על ה- CPU, שיכול להאט את התעבורה של המידע העובר דרכו.
כלי אחר העומד לרשותנו הינו נתח הפרוטוקולים. הכלי הנפוץ ביותר הינו Wireshark (לשעבר Ethereal), שהינו כלי קוד פתוח, נוח וידידותי לעבודה. כלים נוספים הינם Sniffer® של חברת NAI, Netscout ואחרים. הטעות הנפוצה שאני שומע בקשר לכלי זה היא, שהלקוח מזמין "בדיקת Sniffer", ולא חשוב מה הבעיה. חשוב להדגיש, שנתח הפרוטוקולים הינו כלי מתוך סוגים רבים ומגוונים של כלים, שבא לתת לנו פתרון נקודתי של ניתוח רשת לעומק. הוא לא מכשיר פלא שיפתור את כל בעיותינו.
באמצעות נתח הפרוטוקולים נוכל להתחבר במקביל לרכיבים ברשת. כמו שרתים קריטיים, לנתב המחבר אותנו לסניפים, ל- FW המחבר אותנו לאינטרנט וכד’. באמצעותו, נוכל לנתח תפעול של איטיות ברשת, באפליקציה מסוימת, ואפילו בסוג עבודה מסוים באותה האפליקציה. באמצעות כלים אלו נוכל לראות האם היישום הינו יעיל (כמו היישום בבחירות בתחילת מאמר זה), האם TCP עובד בצורה יעילה, ועוד.
כלים חשובים נוספים שישמשו אותנו לבדיקות נקודתיות ורציפות של הרשת הינם כלי SNMP. כלים אלו, אם נגדיר אותם בצורה טובה, יתנו לו אינדיקציה על הקורה ברשת, נקודתית ולאורך זמן. כלים אלו גם יכולים להיות בשימוש עבור התראות, מפות רשת ועוד.
באמצעות כלי SNMP, נוכל לבדוק לאורך זמן עומס על קווים ברשת, שגיאות מסוגים שונים, עומס על משאבי רשת, ניסיונות גישה לרשת, וכן נתונים רבים נוספים. כך למשל נוכל לראות האם יש קצב שגיאות על ממשק מסוים שמוביל לאיטיות, האם יש עומס על קווים מסוימים, מספר שיחות טלפון שעוברות ברשת ועוד. חשוב להדגיש, שכלי SNMP הם ברובם פשוטים, זולים וקלים לתפעול.
משפחה נוספת של כלים אלו הם הכלים המיוחדים, שנועדו לתת פתרון לצרכים מיוחדים. כך למשל יהיו כלים, שיאשרו לנו לבדוק מי מחובר לאיזה מבוא במתג. כלים שיאפשרו לנו לבדוק TCP Ports, כלי סימולציה פשוטים, למשל, I-Perf לדימוי עומס ברשת ועוד.
משפחה חשובה של כלים כאן היא ה- Netflow, שמאפשרת לנו לקבל דוחות סטטיסטיים על המשתמשים ברשת, מי מחובר לאן, באיזה יישומים, מה רוחב הפס שהוא צורך ועוד. כלי זה מאפשר לנו ניתוח עומסים ברמת דיוק גבוהה לניטור "שודדי משאבים" למיניהם.
אחרונים ברשימה והמורכבים מכולם הינם כלי בדיקה ייעודיים, כמו כלי סימולציה, בדיקת אפליקציות וכד’. כלים אלו ישמשו אותנו לבדיקת בעיות רשת ואפליקציה מורכבות עם רמת סיבוך גבוהה.
כלים מסוג זה הינם כלים יקרים מאוד, וישמשו, למשל, לבדיקת אתרי WEB בעומס גבוה, סימולציה של קווי תקשורת תחת סוגי עומסים שונים וכד’.
סיכום ביניים:
דיברנו על כלים רבים ושונים, וחשוב להדגיש, שכל הכלים כולם לא יחליפו את הצורך בידע, עבודה מסודרת ושיטתית והגיון פשוט. כמו שמישהו אמר פעם, שלרופא טוב יספיק הסטטוסקופ לאיתור רבות מהמחלות, כך לאיש תקשורת טוב יספיקו ברוב המקרים כלי הבדיקה הבסיסיים, והבנת אופן העבודה של רשת תקשורת.
רבות מהבעיות בהן נתקלנו במשך השנים נפתרו באמצעות הגיון פשוט. לדוגמא, כתובות IP כפולות (Duplicate Address), ומשולשות שנובעות בד"כ מציוד שמגיע מוגדר מראש עם כתובת לא נכונה, או מציוד שהותקן ברשת ומחלק כתובות מבלי שידוע לנו על כך. לדוגמא: קווי תקשורת עמוסים שהתבררו בבדיקת Wireshark פשוטה כתולעת (Worm) שמעמיסה את הקווים, בעיות בסיסי נתונים כאשר מסך מסוים בתוכנה פשוט "נתקע", או מצב בו Client שולח ל- Server ומקבל ממנו אלפי מנות כאשר ה- Delay של הקו פשוט גבוה מדי לאופן העבודה. במקרים אחרים, אותרו קווי תקשורת שנראו כאיטיים, אולם בבדיקה פשוטה נמצא כי השרתים אינם חזקים מספיק, ולכן קו התקשורת פשוט אינו מנוצל.
אפשרויות נוספות שלא דנו בהן במאמר זה הינן בדיקות משולבות של מספר Probs באתרים שונים, כלי סימולציה ועוד. נשתדל לדון בהן באחד מהמאמרים הבאים. נושאים נוספים שנדון בהם הינם עבודה בכלים השונים, איתור תקלות ברשתות VoIP, ועוד.
לסיכום
חברת אגינקס תקשורת ומחשוב מעורבת בפרויקטים רבים של תקשורת. אנו מעורבים בכל תחומי ה- ICT ובכל סוגי הארגונים ועסקים.
אנו מכריזים כאן על יצירת שיתוף פעולה חדש בין חברת אגינקס תקשורת ומחשוב לחברת NDI לביצוע ניהול ואופטימיזציה של רשתות ארגוניות – WAN Optimization, כשירות מנוהל לעסקים, תוך שימוש בטכניקות דחיסה מגוונות לניצול יעיל של רוחב הפס ושימוש בכלים מיוחדים לאיתור תקלות ברשתות ארגוניות. זאת, תוך חיסכון בהוצאות על תשתיות התקשורת הארגוניות.
אנו עומדים לרשותך להציע לך את שירותי הייעוץ המתקדמים והאיכותיים ביותר שניתן, עם צוות מקצועי וכלים המתקדמים ביותר. צור איתנו קשר ותהיה מוכן לחסוך – ובגדול. לקבלת הצעה ללא התחייבות, לחץ כאן.