מערכות ניטור תנועה ברשתות VoIP. חלק שני - עקרונות הארגון

שלום עמיתים!

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

ארכיטקטורה של מערכות ניטור תעבורה VoIP

בנינו ובנינו ולבסוף בנינו. הידד!
מתוך הקריקטורה "צ'בורשקה וג'נה התנין".

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

מהרגע שהמדען הרוסי הגדול ולדימיר אלכסנדרוביץ' קוטלניקוב יצר את משפט הדגימה, האנושות קיבלה הזדמנות אדירה לבצע המרות אנלוגיות לדיגיטליות ודיגיטליות לאנלוגיות של אותות דיבור, שבזכותה נוכל להשתמש במלואו בסוג נפלא שכזה. של תקשורת כטלפוניה IP. אם מסתכלים על הפיתוח של מנגנונים לעיבוד אותות דיבור (המכונה אלגוריתמים, קודקים, שיטות קידוד וכו'), ניתן לראות כיצד DSP (עיבוד אותות דיגיטלי) לקח צעד מהותי בקידוד הודעות מידע - הטמעת היכולת לחזות אות דיבור. כלומר, במקום פשוט לבצע דיגיטציה ולהשתמש בחוקי דחיסה a-ו-u (G.711A/G.711U), כעת ניתן לשדר רק חלק מהדגימות ולאחר מכן לשחזר מהן את כל ההודעה, מה שחוסך משמעותית רוחב פס. אם נחזור לנושא ה-MMT, נציין שכרגע אין שינויים איכותיים דומים בגישה ללכידת תנועה, מלבד סוג כזה או אחר של שיקוף.

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

איור 1. תרשים כללי של ארכיטקטורת SMT.

כמעט כל SMT מורכב משני מרכיבים עיקריים: שרת וסוכני לכידת תעבורה (או בדיקות). השרת קולט, מעבד ומאחסן תעבורת VoIP שמגיעה מסוכנים, וכן מספק למומחים את היכולת לעבוד עם המידע המתקבל בתצוגות שונות (גרפים, דיאגרמות, Call Flow וכו'). סוכני לכידה מקבלים תעבורת VoIP מציוד ליבת הרשת (לדוגמה, SBC, softswitch, gateways,...), ממירים אותה לפורמט המשמש בתוכנת שרת המערכת המיושמת, ומעבירים אותה לזו האחרונה לצורך מניפולציות עוקבות.

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

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

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

אז, הדבר הראשון שמומחים תמיד מתעניינים בו בעת יישום SMT הוא אילו מאפייני ביצועים יש להשתמש בשרת? בהתחשב בשימוש הנרחב בתוכנה חופשית, שאלה זו נשאלת כל כך הרבה פעמים עד כי ניתן להשוות את הפופולריות שלה לשאלה "מה עלי לעשות?" שנשאל על ידי ניקולאי גברילוביץ' צ'רנישבסקי... הגורם העיקרי המשפיע על התשובה הוא מספר הפעלות מדיה שמעובדות או יעובדו על ידי פלטפורמת הטלפוניה. מאפיין מספרי ומוחשי שנותן הערכה ספציפית של הגורם שצוין הוא פרמטר CAPS (Call Attempts Per Second) או מספר השיחות בשנייה. הצורך לענות על שאלה זו נובע בעיקר מהעובדה שמידע על הפעלות שנשלח למערכת הוא שייצור עומס על השרת שלה.

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

ולבסוף... "יש כל כך הרבה במילה הזו": שרת, וירטואליזציה, קונטיינריזציה... ההיבט האחרון, אך חשוב מאוד שנגע בחלק זה של המאמר הוא הדרכים האפשריות להתקנת רכיבי MMT במהלך הפריסה שלו. רשום לצד ציטוט מיצירתו האלמותית של א.ש. טכנולוגיות פושקין נמצאות בשימוש נרחב בתשתיות ופרויקטים שונים. מצד אחד, הם קשורים זה בזה באופן הדוק, ומצד שני, הם נבדלים זה מזה בקריטריונים רבים. עם זאת, כולם, בצורה זו או אחרת, מוצגים על ידי מפתחים כאפשרויות זמינות להתקנת המוצרים שלהם. לסיכום המערכות המפורטות בחלק הראשון של המאמר, נציין את השיטות הבאות לפריסתן בשרת פיזי או במכונה וירטואלית:
- שימוש בסקריפטים של התקנה אוטומטית או התקנה עצמית ותצורה שלאחר מכן של התוכנה המתאימה,
- שימוש בתמונת מערכת הפעלה מוכנה עם תוכנת SMT מותקנת מראש ו/או סוכן,
- שימוש בטכנולוגיית מכולות (Docker).

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

זהו מאמר נוסף המוקדש למרכיב חשוב ומעניין ברשת ה-VoIP - מערכת ניטור התעבורה SIP. כמו תמיד, אני מודה לקוראים על תשומת לבם לחומר זה! בחלק הבא ננסה להעמיק עוד יותר בפרטים הספציפיים ולהסתכל על מוצרי HOMER SIP Capture ו-SIP3.

מקור: www.habr.com