הכן את הסביבה שלך

ניתן לפרוס את ה-XSPs של Broadworks ישירות באינטרנט, או שהם יכולים לגור ב-DMZ בחזית על ידי רכיב איזון עומסים כגון ה-F5 BIG-IP. כדי לספק יתירות גיאוגרפית, ניתן לפרוס את ה-XSP בשני מערכי נתונים (או יותר), כל אחד יכול להיות מובל על ידי מאזני עומסים, לכל אחד יש כתובת IP ציבורית. אם ה-XSP נמצא מאחורי איזון עומסים, המיקרו-שירותים של Webex והיישום יראו רק את כתובת ה-IP של מאזני העומסים ונראה כי ל-BroadWORKS יש רק XSP אחד, גם אם יש מספר XSPs מאחור.

בדוגמה שלהלן, ה-XSP פרוסים בשני אתרים, אתר A ואתר B. ישנם שני XSP המופעלים על ידי Load Balancer בכל אתר. לאתר A יש XSP1 ו-XSP2 על ידי LB1, ולאתר B יש XSP3 ו-XSP4 על ידי LB2. רק מאזני העומס נחשפים ברשת הציבורית, וה-XSP נמצאים ברשתות הפרטיות DMZ.

תצורת DNS

המיקרו-שירותים של ענן Webex חייבים להיות מסוגלים למצוא את שרתי Broadworks XSP עבור ההתחברות לממשקי Xsi, שירות האימות ו-CTI.

המיקרו-שירותים של ענן Webex יבצעו בדיקת DNS A/AAAA של שם המארח שהוגדר של XSP ויתחבר לכתובת ה-IP המוחזרת. זה יכול להיות רכיב קצה איזון עומסים, או שהוא יכול להיות שרת XSP עצמו. אם תוחזרו כתובות IP מרובות, ה-IP הראשון ברשימה ייבחר. בדיקת מידע של SRV אינה נתמכת כעת.

דוגמה: ה-DNS של השותף הוא רשומת לגילוי של שרת ה-XSP המאוזן של Round-Robin XSP/Load Balancers.

יתירות כשל

כאשר המיקרו-שירותים של Webex שולחים בקשה ל-XSP/Load Balancer והבקשה נכשלת, מספר דברים יכולים לקרות:

• אם הכישלון נובע משגיאת רשת (לדוגמה: TCP, SSL), שירותי המיקרו של WEBEX מסמנים את ה-IP כחסומים ומבצעים באופן מיידי התקדמות ניתוב אל ה-IP הבא.

• אם מוחזר קוד שגיאה (HTTP 5xx), המיקרו שירותים של Webex מסמנים את ה-IP כנחסם ומבצעים מיד נתיב עבור ה-IP הבא.

• אם לא מתקבלת תגובת HTTP בתוך 2 שניות, זמני הבקשה מסתיימים והמיקרו-שירותים של WEBEX מסמנים את ה-IP כחסומים ומבצעים נתיב מתקדם אל ה-IP הבא.

כל בקשה מנוסחת 3 פעמים לפני שדווח על כשל בחזרה לשירות המיקרו.

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

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

מצב

ניתן לראות את מצב הקישוריות של שירותי ענן Webex ל-XSP או מאזני העומס ב-Control Hub. תחת אשכול שיחות BroadWorks, מצב חיבור מוצג עבור כל אחד מהממשקים הבאים:

• פעולות XSI

• אירועי XSI

• שירות אימות

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

• ירוק: כאשר ניתן להשיג את הממשק באחד מכתובות ה-IP בבדיקת רשומה A.

• אדום: כאשר כל כתובות ה-IP בבדיקת רשומה A אינן זמינות והממשק אינו זמין.

השירותים הבאים משתמשים בשירותים המיקרו-שירותים כדי להתחבר אל ה-XSP ומושפעים מזמינות ממשק XSP:

• התחברות ליישום Webex

• רענון אסימון יישום Webex

• דוא"ל/הפעלה עצמית לא מהימנה

• בדיקת תקינות שירות Broadworks

תצורת DNS

יישום Webex ניגש לממשק השירותים של Xtended (פעולות XSI & אירועי XSI) ושירותי ניהול מכשירים (DMS) ב-XSP.

כדי למצוא את שירות XSI, יישום WEBEX מבצע חיפוש DNS SRV עבור _xsi-client._tcp.<webex app xsi domain>. ה-SRV מצביע על כתובת ה-URL המוגדרת עבור מארחי XSP או מאזני טעינה עבור שירות XSI. אם בדיקת SRV אינה זמינה, יישום Webex יחזור לחיפוש A/AAAA.

ה-SRV יכול לפתור למספר מטרות A/AAAA. עם זאת, כל רשומת A/AAAA חייבת למפות לכתובת IP אחת בלבד. אם יש XSPs מרובים ב-DMZ מאחורי מכשיר איזון העומס/קצה, נדרש להגדיר את איזון העומס כדי לשמור על התמדה של הפעלה כדי לנתב את כל הבקשות של אותה הפעלה לאותו XSP. אנו מנדט תצורה זו משום שפעימות הלב של XSI-אירוע של הלקוח חייבות לעבור לאותו XSP המשמש להקמת ערוץ האירוע.

לדוגמה 1, רשומת A/AAAA עבור webex-app-xsp.example.com אינה קיימת ואינה צריכה. אם ה-DNS דורש שיש להגדיר רשומת A/AAAA אחת, יש להחזיר רק כתובת IP של 1. בכל מקרה, יש עדיין להגדיר את ה-SRV עבור יישום Webex. אם יישום Webex משתמש בשם A/AAAA שפותר ליותר מכתובת IP אחת, או אם רכיב איזון העומס/קצה אינו שומר על התמדה של מושב, הלקוח בסופו של דבר שולח פעימות לב ל-XSP שבו הוא לא הקים ערוץ אירועים. התוצאה היא שבערוץ נקרע, וגם בתעבורה פנימית משמעותית יותר הפוגעת בביצועי אשכול XSP שלך. מכיוון שלענן Webex ויישום Webex יש דרישות שונות בבדיקת רשומות A/AAAA, עליך להשתמש ב-FQDN נפרד עבור ענן Webex ויישום Webex כדי לגשת ל-XSP שלך. כפי שמוצג בדוגמאות, ענן Webex משתמש ברשומה webex-cloud-xsp.example.com, ויישום Webex משתמש ב-SRV _xsi-client._tcp.webex-app-xsp.example.com.

דוגמה 1—מספר XSPs, כל אחד מאחורי מאזני טעינה נפרדים

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

דוגמה 2—מספר XSPs מאחורי איזון עומסים יחיד (עם גשר TLS)

עבור הבקשה הראשונית, איזון הטעינה בוחר XSP אקראי. ש-XSP מחזיר קובץ Cookie שיישום Webex כולל בבקשות עתידיות. לבקשות עתידיות, איזון העומס משתמש בעוגייה כדי לנתב את החיבור ל-XSP הנכון, כדי להבטיח שערוץ האירוע לא יתנתק.

כתובת DMS

במהלך תהליך ההתחברות, יישום Webex יאחזר גם את כתובת ה-URL של DMS כדי להוריד את קובץ התצורה שלו. המארח בכתובת ה-URL יתפרק ויישום WeBEX יבצע בדיקת DNS A/AAAA של המארח כדי להתחבר ל-XSP שמארח את שירות ה-DMS.

דוגמה: רשומת DNS A לגילוי של שרת XSP מאוזן הפונה-רובין באינטרנט/מאזני טעינה מאת יישום WEBEX כדי להוריד קבצי תצורה דרך DMS:

כיצד יישום Webex מוצא כתובות XSP

הלקוח מנסה לאתר את צמתי XSP באמצעות זרימת ה-DNS הבאה:

1. הלקוח מאחזר בתחילה כתובות URL של פעולות/Xsi-Events מענן Webex (הזנת אותם בעת יצירת אשכול השיחות המשויך של BroadWorks). שם המארח/דומיין XSI מנותח מכתובת ה-URL והלקוח מבצע בדיקת SRV באופן הבא:

   1. הלקוח מבצע חיפוש SRV עבור _xsi-לקוח._tcp.<xsi domain="">

   2. אם בדיקת ה-SRV מחזירה יעד A/AAAA אחד או יותר:

      1. הלקוח מבצע חיפוש A/AAAA עבור יעדים אלה ומטמון את כתובות ה-IP המוחזרות.

      2. הלקוח מתחבר לאחד היעדים (ולכן רשומת A/AAAA שלו עם כתובת IP בודדת) בהתבסס על עדיפות SRV, משקל (או באופן אקראי אם כולם שווים).

   3. אם בדיקת ה-SRV לא מחזירה מטרות כלשהן:

      הלקוח מבצע חיפוש A/AAAA של הפרמטר שורש XSI ולאחר מכן מנסה להתחבר לכתובת ה-IP המוחזרת. זה יכול להיות רכיב קצה איזון עומסים, או שהוא יכול להיות שרת XSP עצמו.

      כפי שצוין, רשומת A/AAAA חייבת לפתור לכתובת IP אחת מאותן סיבות.

2. (אופציונלי) ייתכן שתספק לאחר מכן פרטים מותאמים אישית של פעולות XSI/XSI-Events בתצורת המכשיר עבור יישום Webex, באמצעות התגים הבאים:

   <protocols>
   	<xsi>
   		<paths>
   			<root>%XSI_ROOT_WXT%</root>
   			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
   			<events>%XSI_EVENTS_PATH_WXT%</events>
   		</paths>
   	</xsi>
   </protocols>

   1. פרמטרי תצורה אלה מקבלים קדימות על כל תצורה באשכול BroadWorks ב-Control Hub.

   2. אם הם קיימים, הלקוח ישווה כנגד כתובת XSI המקורית שהיא התקבלה באמצעות תצורת אשכול BroadWorks.

   3. אם זוהה הבדל כלשהו, הלקוח יבצע אתחול מחדש של קישוריות XSI/ XSI Events שלו. השלב הראשון בזה הוא לבצע את אותו תהליך חיפוש DNS המופיע תחת שלב 1 – הפעם מבקש בדיקה עבור הערך בפרמטר %XSI_ROOT_WXT% מקובץ התצורה שלו.

      הקפד ליצור את רשומות ה-SRV התואמות אם אתה משתמש בתג זה כדי לשנות את ממשקי ה-Xsi.

יתירות כשל

במהלך ההתחברות, יישום Webex מבצע חיפוש DNS SRV עבור _xsi-client._tcp.<xsi domain="">, בונה רשימה של מארחים ומתחבר לאחד מהמארחים בהתבסס על העדיפות של SRV, ולאחר מכן המשקל. המארח המחובר הזה הופך למארח שנבחר עבור כל הבקשות העתידיות. לאחר מכן נפתח ערוץ אירועים למארח שנבחר ודופק נשלח באופן קבוע כדי לאמת את הערוץ. כל הבקשות שנשלחו לאחר הראשונה כוללות קובץ cookie שמוחזר בתגובת ה-HTTP, לכן, חשוב שמאזן העומס שומר על התמדה של ההפעלה (זיקה) ותמיד שולח בקשות לאותו שרת XSP backend.

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

• אם הכישלון נובע משגיאת רשת (לדוגמה: TCP, SSL), נתיב יישום Webex מתקדם באופן מיידי למארח הבא ברשימה.

• אם מוחזר קוד שגיאה (HTTP 5xx), יישום Webex מסמן את כתובת ה-IP כנחמת ומנתב מתקדמת למארח הבא ברשימה.

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

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

במקרה של פעימות לב, אם קיימים שני כשלי בקשה רציפים, יישום Webex יאתחל מחדש את ערוץ האירוע.

שים לב שיישום Webex אינו מבצע גיבוי, וגילוי שירות DNS מתבצע פעם אחת בלבד בכניסה.

במהלך הכניסה, יישום Webex מנסה להוריד את קובץ התצורה דרך ממשק XSP/Dms. הוא מבצע בדיקת שיא A/AAAA של המארח בכתובת ה-URL של ה-DMS שאוחזרה ומתחבר ל-IP הראשון. תחילה ינסה לשלוח את הבקשה להורדת קובץ התצורה באמצעות אסימון SSO. אם אפשרות זו נכשלת מכל סיבה שהיא, היא תנסה שוב אך עם שם המשתמש והסיסמה של המכשיר.