- בית
- /
- מאמר
הטמעת זמינות גבוהה של CUBE כשער מקומי
שער מקומי (LGW) הוא הפתרון הבלעדי למתן גישת PSTN מקומית ללקוחות Cisco Webex Calling. מסמך זה מנחה אותך בקביעת התצורה של שער מקומי באמצעות זמינות גבוהה של CUBE, עם רכיבי CUBE פעילים או במצב המתנה, כדי להבטיח יתירות כשל עם מצב של שיחות פעילות.
יסודות
תנאים מוקדמים
לפני שתפרוס את Cisco Unified Border Element (CUBE) זמינות גבוהה (HA) כשער מקומי עבור Webex Calling, ודא שיש לך הבנה מעמיקה של המושגים הבאים:
-
יתירות מקופסה לקופסה בשכבה 2 עם CUBE Enterprise לשימור שיחות עם מצב
הנחיות התצורה המפורטות במאמר זה כוללות פלטפורמת שער מקומי ייעודית ללא תצורת קול קיימת. אם פריסה ארגונית קיימת של CUBE משתנה כדי להשתמש גם בפונקציית השער המקומי עבור Cisco Webex Calling, שים לב היטב לתצורה שהוחלה כדי להבטיח שזרימות השיחות והפונקציונליות הקיימות אינן משתבשות וודא שאתה עומד בדרישות העיצוב של CUBE HA.
רכיבי חומרה ותוכנה
CUBE HA כשער מקומי דורש את IOS-XE גרסה 17.9.1 ואילך ופלטפורמה שבה פונקציות CUBE HA ו-LGW נתמכות.
פקודות התצוגה ויומני הרישום במאמר זה מבוססים על מהדורת תוכנה מינימלית של Cisco IOS-XE 17.9.1 המיושמת על vCUBE (CSR 8000v).
חומר עזר
הנה כמה מדריכי תצורה מפורטים של CUBE HA עבור פלטפורמות שונות:
-
Cisco ISR 4K וסדרת Cisco Catalyst 8K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
הארכיטקטורה המועדפת של Cisco עבור Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
סקירה כללית של פתרון Webex Calling
Cisco Webex Calling היא הצעת שיתוף פעולה המספקת חלופה מבוססת ענן מרובת דיירים לשירות טלפון PBX מקומי עם אפשרויות PSTN מרובות ללקוחות.
פריסת השער המקומי (המיוצגת להלן) היא המוקד של מאמר זה. ה-trunk של שער מקומי (PSTN המבוסס על הסביבה המקומית) ב-Webex Calling מאפשר קישוריות לשירות PSTN בבעלות לקוח. הוא גם מספק קישוריות לפריסת IP PBX מקומית כגון Cisco Unified CM. כל התקשורת אל הענן וממנו מאובטחת באמצעות תעבורת TLS עבור SIP ו-SRTP עבור מדיה.
האיור שלהלן מציג פריסה של Webex Calling ללא IP PBX קיים והוא חל על פריסה יחידה או על פריסה מרובת אתרים. התצורה המתוארת במאמר זה מבוססת על פריסה זו.
יתירות מקופסה לקופסה בשכבה 2
יתירות מקופסה לקופסה בשכבה 2 של CUBE HA משתמשת בפרוטוקול התשתית של קבוצת היתירות (RG) כדי ליצור זוג נתבים פעילים/במצב המתנה. זוג זה משתף את אותה כתובת IP וירטואלית (VIP) בממשקים המתאימים שלו ומחליף ללא הרף הודעות מצב. פרטי ההפעלה של CUBE נבדקים באמצעות סימון על פני צמד הנתבים, ומאפשרים לנתב במצב המתנה לקחת על עצמו את כל תחומי האחריות לעיבוד שיחות CUBE באופן מיידי אם הנתב הפעיל יוצא מכלל שימוש, וכתוצאה מכך שמירה על מצב של איתות ומדיה.
בדיקת המצביעים מוגבלת לשיחות מחוברות עם מנות מדיה. שיחות במעבר אינן מחוברות לבדיקה (לדוגמה, מצב מנסה או מצלצל).
במאמר זה, CUBE HA מתייחס ליתירות מקופסה לקופסה בשכבה 2 של CUBE זמינות גבוהה (HA) לשכבה 2 (B2B) לשימור שיחות עם מצב.
החל מ-IOS-XE 17.9.1, ניתן לפרוס את CUBE HA כשער מקומי עבור פריסות trunk של Cisco Webex Calling (PSTN המבוסס על הסביבה המקומית). מאמר זה ידון בשיקולי עיצוב ותצורות. האיור מציג הגדרת CUBE HA טיפוסית כשער מקומי עבור פריסת trunk של Cisco Webex Calling.
רכיב אינפרא של קבוצת יתירות
רכיב האינפרה של קבוצת היתירות (RG) מספק את התמיכה בתשתית התקשורת מקופסה לקופסה בין שני רכיבי ה-CUBE ומנהל משא ומתן על מצב היתירות היציב הסופי. הרכיב הזה מספק גם:
-
פרוטוקול דמוי HSRP שמנהל משא ומתן על מצב היתירות הסופי עבור כל נתב על ידי החלפת הודעות keepalive ו-hello בין שני רכיבי ה-CUBE (באמצעות ממשק הבקרה) – GigabitEthernet3 באיור לעיל.
-
מנגנון תעבורה לבדיקת איתות ומצב מדיה עבור כל שיחה מהנתב הפעיל לנתב במצב המתנה (באמצעות ממשק הנתונים) – GigabitEthernet3 באיור לעיל.
-
תצורה וניהול של ממשק IP וירטואלי (VIP) עבור ממשקי התעבורה (ממשקי תעבורה מרובים ניתן להגדיר באמצעות אותה קבוצת RG) – GigabitEthernet 1 ו-2 נחשבים לממשקי תנועה.
יש להגדיר רכיב RG זה במיוחד כדי לתמוך בקול B2B HA.
ניהול כתובות IP וירטואלי (VIP) הן לאיתות והן למדיה
B2B HA מסתמך על VIP כדי להשיג יתירות. ממשקי ה-VIP והממשקים הפיזיים המשויכים בשני רכיבי ה-CUBE בזוג CUBE HA חייבים לשכון באותה רשת משנה של LAN. קביעת תצורה של ה-VIP ואיגוד ממשק ה-VIP ליישום קולי מסוים (SIP) הכרחית לתמיכה קולית ב-B2B HA. מכשירים חיצוניים כגון Unified CM, SBC לגישה ל-Webex Calling, ספק שירות או Proxy, משתמשים ב-VIP ככתובת ה-IP המהווה יעד עבור השיחות החוצות את נתבי CUBE HA. לפיכך, מנקודת מבט של Webex Calling, זוגות CUBE HA פועלים כשער מקומי יחיד.
פרטי איתות השיחות ופרטי הפעלת RTP של שיחות שנוצרו עוברים בדיקה מהנתב הפעיל לנתב במצב המתנה. כאשר הנתב הפעיל מושבת, הנתב במצב המתנה משתלט וממשיך להעביר את זרם ה-RTP שנותב בעבר על-ידי הנתב הראשון.
שיחות במצב ארעי בזמן יתירות כשל לא יישמרו לאחר המעבר. לדוגמה, שיחות שעדיין לא נוצרו במלואן או נמצאות בתהליך של שינוי באמצעות פונקציית העברה או החזקה. שיחות שנוצרו עשויות להתנתק לאחר המעבר.
הדרישות הבאות קיימות לשימוש ב-CUBE HA כשער מקומי ליתירות כשל עם מצב:
-
CUBE HA לא יכול לכלול ממשקים TDM או אנלוגיים במיקום משותף
-
Gig1 ו-Gig2 מכונים ממשקי תעבורה (SIP/RTP) ו-Gig3 הוא ממשק בקרה/נתונים של קבוצת יתירות (RG)
-
לא ניתן למקם יותר מ-2 זוגות CUBE HA באותו דומיין שכבה 2, אחד עם מזהה קבוצה 1 והשני עם מזהה קבוצה 2. אם אתה מגדיר 2 זוגות HA עם אותו מזהה קבוצה, ממשקי בקרה/נתונים של RG צריכים להשתייך לדומיינים שונים של שכבה 2 (vlan, מתג נפרד)
-
ערוץ יציאה נתמך הן עבור ממשקי בקרה/נתונים של RG והן עבור ממשקי תעבורה
-
כל האיתות/המדיה מקורם בכתובת ה-IP הווירטואלית/אליה
-
בכל פעם שפלטפורמה נטענת מחדש במערכת יחסים של CUBE-HA, היא תמיד מאתחלת בתור המתנה.
-
כתובת נמוכה יותר עבור כל הממשקים (Gig1, Gig2, Gig3) צריכה להיות באותה פלטפורמה
-
מזהה ממשק יתירות, rii צריך להיות ייחודי לשילוב זוג/ממשק באותה שכבה 2
-
התצורה בשני רכיבי ה-CUBE חייבת להיות זהה, כולל תצורה פיזית וחייבת לפעול באותו סוג של פלטפורמה וגרסת IOS-XE
-
לא ניתן להשתמש בממשקי Loopback כאיגוד משום שהם תמיד במצב מופעל
-
ממשקי תעבורה מרובים (SIP/RTP) (Gig1, Gig2) דורשים קביעת התצורה של מעקב אחר ממשק
-
CUBE-HA אינו נתמך באמצעות חיבור כבל קרוסאובר עבור קישור בקרה/נתונים של RG (Gig3)
-
שתי הפלטפורמות חייבות להיות זהות ולהיות מחוברות באמצעות מתג פיזי בכל הממשקים דומים כדי ש-CUBE HA יפעל, כלומר GE0/0/0 של CUBE-1 ו-CUBE-2 חייב להסתיים באותו מתג וכן הלאה.
-
WAN לא יכול להסתיים בקובצי CUBE ישירות או ב-HA של נתונים משני הצדדים
-
שניהם פעילים/במצב המתנה חייבים להיות באותו מרכז נתונים
-
חובה להשתמש בממשק L3 נפרד ליתירות (בקרה/נתונים של RG, Gig3). כלומר, ממשק המשמש לתעבורה לא יכול לשמש עבור keepalives של HA ונקודות ביקורת
-
עם יתירות כשל, ה-CUBE שהיה פעיל בעבר עובר טעינה מחדש באמצעות עיצוב, תוך שמירה על איתות ומדיה
קבע תצורה של יתירות בשני רכיבי ה-CUBE
עליך להגדיר יתירות מקופסה לקופסה בשכבה 2 בשני רכיבי ה-CUBE המיועדים לשימוש בזוג HA כדי להעלות כתובות IP וירטואליות.
1 |
קבע תצורה של מעקב אחר ממשק ברמה גלובלית כדי לעקוב אחר מצב הממשק.
ה-CLI של המעקב משמש ב-RG כדי לעקוב אחר מצב ממשק התעבורה הקולית כך שהנתיב הפעיל ימלא את תפקידו הפעיל לאחר שממשק התעבורה יושבת. | ||
2 |
קבע תצורה של RG לשימוש עם VoIP HA תחת מצב המשנה של יתירות היישום.
הנה הסבר על השדות המשמשים בתצורה זו:
| ||
3 |
הפעל יתירות מקופסה לקופסה עבור יישום CUBE. קבע את התצורה של ה-RG מהשלב הקודם תחת
יתירות-קבוצה 1 – הוספה והסרה של פקודה זו מחייבים טעינה מחדש כדי שהתצורה המעודכנת תיכנס לתוקף. נטען מחדש את הפלטפורמות לאחר שכל התצורה תוחל. | ||
4 |
קבע את התצורה של ממשקי Gig1 ו-Gig2 עם כתובות ה-IP הווירטואליות שלהם כפי שמוצג להלן והחל את מזהה ממשק היתירות (rii)
הנה הסבר על השדות המשמשים בתצורה זו:
| ||
5 |
שמור את התצורה של ה-CUBE הראשון וטען אותה מחדש. הפלטפורמה האחרונה לטעינה מחדש היא תמיד במצב המתנה.
לאחר אתחול VCUBE-1 לחלוטין, שמור את התצורה של VCUBE-2 וטען אותה מחדש.
| ||
6 |
ודא שתצורת קופסה לקופסה פועלת כצפוי. הפלט הרלוונטי מודגש במודגש. הטעינו מחדש את VCUBE-2 אחרון ולפי שיקולי העיצוב; הפלטפורמה לטעינה מחדש אחרונה תהיה תמיד במצב המתנה. בשלב הבא, המשך עם תצורת השער המקומי (מבוססת רישום או מבוססת תעודה) בשני רכיבי ה-CUBE של HA. ראה הגדרת שער מקומי ב-Cisco IOS XE עבור Webex Calling. |