הטמעת ExpressRoute עבור Microsoft 365

מאמר זה חל על Microsoft 365 Enterprise.

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

הערה

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

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

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

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

אנו מצפים להשלים את הדרישות המוקדמות הבאות לפני הפעלת מדריך יישום זה.

1. השלמת הערכת רשת כדי לקבוע אם ExpressRoute מומלץ ומאושר.

2. בחרת ספק שירות רשת של ExpressRoute. מצא פרטים אודות שותפי ExpressRoute ומיקומים של עמיתים.

3. כבר קראת וה הבנת את התיעוד של ExpressRoute והרשת הפנימית שלך יכולה לעמוד בדרישות המוקדמות של ExpressRoute מקצה לקצה.

4. הצוות שלך קרא https://aka.ms/expressrouteoffice365את כל ההנחיות והתיעוד הציבוריות ב- , https://aka.ms/ertוצפה בסדרת ההדרכה של Azure ExpressRoute עבור Microsoft 365 בערוץ 9 כדי להבין פרטים טכניים קריטיים, כולל:

   • יחסי התלות באינטרנט של שירותי SaaS.

   • כיצד להימנע מנתובים אסימטריים ולטפל בניתוב מורכב.

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

התחל על-ידי איסוף הדרישות

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

כדי לאסוף את דרישות הארגון שלך:

• קטלוג תעבורת הרשת הנכנסת והתעבורה היוצאת עבור שירותי Microsoft 365 שהארגון שלך משתמש בהם. עיין בדף כתובות URL וטווחי כתובות IP של Microsoft 365 לקבלת תיאור זרימות שדורשות תרחישים שונים של Microsoft 365.

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

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

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

  • זהה את כל מכשירי הקצה, כגון רכיבי Proxy, חומות אש וכן הלאה, וקטלוג קשרי הגומלין שלהם לזרימות דרך האינטרנט ו- ExpressRoute.

  • תמסמך אם משתמשי קצה ניגשים לשירותים של Microsoft 365 באמצעות ניתוב ישיר או Proxy עקיף של יישום עבור זרימות אינטרנט ו- ExpressRoute.

• הוסף את המיקום של הדייר שלך ואת מיקומי ההיכרות שלי לדיאגרמת הרשת שלך.

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

• List company network security and high availability requirements that need to be met with the new ExpressRoute connection. לדוגמה, כיצד משתמשים ממשיכים לקבל גישה ל- Microsoft 365 במקרה של יציאה מהאינטרנט או כשל במעגל ExpressRoute.

• מסמך שבו זרימות רשת נכנסות ויו יוצאות של Microsoft 365 ישתמשו בנתיב האינטרנט, אשר ישתמש ב- ExpressRoute. הפרטים הספציפיים של מיקומים גיאוגרפיים של המשתמשים והפרטים של טופולוגיית הרשת המקומית עשויים לדרוש שהתוכנית תהיה שונה ממיקום משתמש אחד לאחר.

קטלוג תעבורת הרשת היוצאת והתעבורה הנכנסת שלך

כדי למזער את הניתוב ומורכבויות רשת אחרות, מומלץ להשתמש ב- ExpressRoute עבור Microsoft 365 רק עבור זרימות תעבורת הרשת הנדרשות כדי לעבור על חיבור ייעודי עקב דרישות רגולטוריות או כתוצאה מהערכת הרשת. בנוסף, מומלץ לשלב את ההיקף של ניתוב ExpressRoute ולגשת לתזרימי תעבורה של רשת יוצאת ותעבורה נכנסת בתור שלבים שונים ונפרדים של פרוייקט היישום. פרוס את ExpressRoute עבור Microsoft 365 עבור זרימות תעבורה יוצאת של רשת יוצאת על-ידי המשתמש בלבד והשאר זרימות תעבורה נכנסות של הרשת ברחבי האינטרנט יכול לעזור לשלוט בעלייה במורכבות הטופולוגית ובסיכונים הכרים בהצגת אפשרויות ניתוב אסימטריות נוספות.

קטלוג תעבורת הרשת שלך צריך להכיל לוחות רישום של כל חיבורי הרשת הנכנסת והתעבורה היוצאת שיהיה לך בין הרשת המקומית לבין Microsoft.

• תזרימי תעבורה של רשת יוצאת הם תרחישים שבהם חיבור מופעל מהסביבה המקומית שלך, כגון לקוחות פנימיים או שרתים, עם יעד של שירותי Microsoft. חיבורים אלה עשויים להיות ישירים ל- Microsoft 365 או לעקיפה, כגון כאשר החיבור עובר דרך שרתי Proxy, חומות אש או התקני רשת אחרים בנתיב אל Microsoft 365.

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

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

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

עבור כל שירות הדורש חיבור נכנס, תזדקק למידע נוסף. שרתים בענן של Microsoft יבססו חיבורים לרשת המקומית שלך. כדי להבטיח שהחיבורים יבוצעו כראוי, מומלץ לתאר את כל ההיבטים של קישוריות זו, כולל; ערכי ה- DNS הציבוריים עבור השירותים שיקבלו חיבורים נכנסים אלה, כתובות ה- IPv4 המעוצבות של CIDR, ציוד ספק שירותי האינטרנט המעורב ותן לטיפול ב- NAT או במקור הנכנס עבור חיבורים אלה.

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

להלן דוגמה של רמת הפירוט הנדרשת. במקרה זה Exchange Hybrid ינתב אל המערכת המקומית דרך ExpressRoute.

מאפיין חיבור	ערך:
כיוון תעבורת רשת	כניסה
שירות	Exchange היברידי
נקודת קצה ציבורית של Microsoft 365 (מקור)	Exchange Online (כתובות IP)
נקודת קצה ציבורית מקומית (יעד)	5.5.5.5
ערך DNS ציבורי (אינטרנט)	Autodiscover.contoso.com
האם נקודת קצה מקומית זו תשמש עבור שירותים אחרים של Microsoft (שאינם של Microsoft 365)	לא
האם נקודת קצה מקומית זו תשמש משתמשים/מערכות באינטרנט	כן
מערכות פנימיות שפורסמו באמצעות נקודות קצה ציבוריות	Exchange Server גישת לקוח (מקומי) 192.168.101, 192.168.102, 192.168.103
פרסומת IP של נקודת הקצה הציבורית	לאינטרנט: 5.5.0.0/16 אל ExpressRoute: 5.5.5.0/24
פקדי אבטחה/היקף	נתיב אינטרנט: DeviceID_002 ExpressRoute: DeviceID_003
זמינות גבוהה	פעיל/פעיל על-פני 2 מעגלים גיאוגרפיים יתיר / ExpressRoute - שיקגו ודלאלאס
פקד הסימטריה של הנתיב	שיטה: נתיב אינטרנט של מקור NAT: חיבורי NAT נכנסים של מקור לנתיב NAT 192.168.5.5 ExpressRoute: חיבורי NAT של מקור ל- 192.168.1.0 (Chicago) ו- 192.168.2.0 (דאלאס)

להלן דוגמה של שירות היוצא בלבד:

מאפיין חיבור	ערך
כיוון תעבורת רשת	יוצאת
שירות	SharePoint
נקודת קצה מקומית (מקור)	תחנת עבודה של משתמש
נקודת קצה ציבורית של Microsoft 365 (יעד)	SharePoint (כתובות IP)
ערך DNS ציבורי (אינטרנט)	*.sharepoint.com (ועוד FQDN)
הפניות CDN	cdn.sharepointonline.com (ועוד שמות FQDN) - כתובות IP המנוהחות על-ידי ספקי CDN)
פרסומת IP ו- NAT בשימוש	נתיב אינטרנט/מקור NAT: 1.1.1.0/24 נתיב ExpressRoute/מקור NAT: 1.1.2.0/24 (Chicago) ו- 1.1.3.0/24 (דאלאס)
שיטת קישוריות	אינטרנט: באמצעות Proxy של שכבה 7 (קובץ .pac) ExpressRoute: ניתוב ישיר (ללא Proxy)
פקדי אבטחה/היקף	נתיב אינטרנט: DeviceID_002 נתיב ExpressRoute: DeviceID_003
זמינות גבוהה	נתיב אינטרנט: יציאה עודפת של אינטרנט נתיב ExpressRoute: ניתוב 'תפוח אדמה חם' פעיל/פעיל על-פני 2 מעגלי ExpressRoute יתירות גיאוגרפית - Chicago ו- Dallas
פקד הסימטריה של הנתיב	שיטה: NAT מקור עבור כל החיבורים

עיצוב טופולוגיית הרשת שלך עם קישוריות אזורית

לאחר שתבין את השירותים ואת תזרימי תעבורת הרשת המשויכים להם, תוכל ליצור דיאגרמת רשת המשלבת דרישות קישוריות חדשות אלה וממחישה את השינויים שתבצע כדי להשתמש ב- ExpressRoute עבור Microsoft 365. הדיאגרמה שלך צריכה לכלול:

1. כל מיקומי המשתמשים שבהם Microsoft 365 ושירותים אחרים יתבצע אליהם גישה.

2. כל נקודות היציאה של האינטרנט ו- ExpressRoute.

3. כל ההתקנים היוצאים והתעבורה הנכנסת שמנהלים את הקישוריות בתוך הרשת ויציאה אליה, כולל נתבים, חומות אש, שרתי Proxy של אפליקציות וזיהוי/מניעה של הפרעה.

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

5. קטלוג של כל רשתות המשנה של IP שיתפרספו

6. זהה כל מיקום שבו אנשים יוכלו לגשת ל- Microsoft 365 מ- Microsoft 365 ולבצע רשימה של המיקומים העומדים בדרישות שישמש עבור ExpressRoute.

7. מיקומים בחלקים של טופולוגיית הרשת הפנימית שלך, שבה קידומות IP של Microsoft שלמדו מ- ExpressRoute יתקבלו, ילסנן ולהפצתן.

8. טופולוגיית הרשת אמורה להמחיש את המיקום הגיאוגרפי של כל מקטע רשת ואת האופן שבו היא מתחברת לרשת Microsoft באמצעות ExpressRoute ו/או האינטרנט.

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

עבור תעבורה יוצאת, האנשים ניגשים ל- Microsoft 365 באחת משלוש דרכים:

1. דרך מיקום פגוש אותי בצפון אמריקה עבור האנשים בקליפורניה.

2. דרך מיקום פגוש אותי באזור מנהלי מיוחד של הונג קונג עבור האנשים בהונג קונג SAR.

3. דרך האינטרנט בנגלדש שבו יש פחות אנשים ולא מוקצה מעגל ExpressRoute.

באופן דומה, תעבורת הרשת הנכנסת מ- Microsoft 365 חוזרת באחת משלוש דרכים:

1. דרך מיקום פגוש אותי בצפון אמריקה עבור האנשים בקליפורניה.

2. דרך מיקום פגוש אותי באזור מנהלי מיוחד של הונג קונג עבור האנשים בהונג קונג SAR.

3. דרך האינטרנט בנגלדש שבו יש פחות אנשים ולא מוקצה מעגל ExpressRoute.

קביעת המיקום המתאים של meet-me

מבחר המיקומים מסוג Meet-me, שהם המיקום הפיזי שבו מעגל ExpressRoute מחבר את הרשת שלך לרשת Microsoft, מושפע מהמיקומים שבהם אנשים ניגשים ל- Microsoft 365. כהצעת SaaS, Microsoft 365 אינו פועל תחת המודל האזורי IaaS או PaaS באותו אופן שבו Azure פועל. במקום זאת, Microsoft 365 הוא ערכה מבוזרת של שירותי שיתוף פעולה, שבה ייתכן שהמשתמשים יצטרכו להתחבר ל נקודות קצה בין מרכזי נתונים ואזורים מרובים, וייתכן שלא בהכרח נמצאים באותו מיקום או אזור שבו מתארח הדייר של המשתמש.

משמעות הדבר היא שהשיקול החשוב ביותר שעליך לקחת בחשבון בעת בחירת מיקומים של Meet-me עבור ExpressRoute עבור Microsoft 365 הוא המקום שבו האנשים בארגון שלך יתחברו. ההמלצה הכללית לקישוריות מיטבית של Microsoft 365 היא ליישם ניתוב, כך שבקשות משתמש לשירותים של Microsoft 365 נשלחות לרשת Microsoft בנתיב הרשת הקצר ביותר, לעתים קרובות, פעולה זו נקראת גם ניתוב 'תפוח אדמה חם'. לדוגמה, אם רוב משתמשי Microsoft 365 נמצאים במיקום אחד או שניים, בחירת מיקומים מסוג 'הכר אותי' הנמצאים בקירבה הקרובה ביותר למיקום של משתמשים אלה תיצור את העיצוב האופטימלי. אם החברה שלך כוללת אוכלוסיות משתמשים גדולות באזורים רבים ושונות, מומלץ לשקול מעגלים מרובים של ExpressRoute ומיקומים של 'הכר אותי'. עבור חלק ממיקומים של המשתמשים שלך, ייתכן שהנתיב הקצר/האופטימלי ביותר אל רשת Microsoft ו- Microsoft 365 לא עובר דרך נקודות ההיכרות הפנימיות של WAN ו- ExpressRoute, אלא דרך האינטרנט.

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

מיקומים מועדפת של ExpressRoute בקליפורניה וב ניו יורק

מיקום	מספר אנשים	השהיה צפויה לרשת Microsoft דרך יציאה מהאינטרנט	השהיה צפויה לרשת Microsoft באמצעות ExpressRoute
לוס אנג'לס	10,000	~15ms	~10ms (דרך עמק הסיליקון)
וושינגטון די.סי.	15,000	~20ms	~10ms (דרך ניו יורק)
דאלאס	5,000	~15ms	~40ms (דרך ניו יורק)

לאחר שפותחה ארכיטקטורת הרשת הגלובלית המציגה את האזור של Microsoft 365, ספק שירותי הרשת ExpressRoute, מיקומי meet-me וכמות האנשים לפי מיקום פותחה, ניתן להשתמש בה כדי לזהות אם ניתן לבצע מיטובים. היא עשויה גם להציג חיבורי רשת גלובליים של הצמדת שיער, שבהם נתיבי תנועה למיקום רחוק יותר כדי לקבל את המיקום של 'פגוש אותי'. אם התגלה הצמדה לרשת הגלובלית, יש תיקון לפני שתמשיך. תוכל למצוא מיקום אחר של פגוש אותי, או להשתמש בנקודות יציאה סלקטיביות של פיצול אינטרנט כדי להימנע מההצמדה.

הדיאגרמה הראשונה מציגה דוגמה של לקוח עם שני מיקומים פיזיים בצפון אמריקה. באפשרותך לראות את המידע אודות מיקומי Office, מיקומי דיירים של Microsoft 365 ומספר אפשרויות עבור מיקומי ההיכרות של ExpressRoute. בדוגמה זו, הלקוח בחר את המיקום 'הכר אותי' בהתבסס על שני עקרונות, לפי הסדר:

1. הקירבה הקרובה ביותר לאנשים בארגון שלהם.

2. מרכז הנתונים הקרוב ביותר ל- Microsoft שבו מתארח Microsoft 365.

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

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

Create היישום של ExpressRoute for Microsoft 365

תוכנית היישום שלך צריכה לכלול הן את הפרטים הטכניים של קביעת התצורה של ExpressRoute והן את הפרטים של קביעת התצורה של כל התשתית האחרת ברשת שלך, כגון אלה.

• תכנן אילו שירותים מפוצלים בין ExpressRoute לאינטרנט.

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

• עיצוב ניתוב נכנס ותעבורה יוצאת, כולל מיטובים נאותים של נתיבי ניתוב עבור מיקומים שונים

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

• תכנון שינויים ברשומת DNS, כולל ערכי מסגרת מדיניות שולח.

• אסטרטגיית תוכנית NAT, כולל NAT של מקור יוצא ומקור נכנס.

תכנון הניתוב באמצעות נתיבי רשת באינטרנט וברשת ExpressRoute

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

• תכנן ניתוב LAN של לקוח משתמש קצה, כגון קביעת תצורה של קובץ PAC/WPAD, נתיב ברירת מחדל, שרתי Proxy ומודעות ניתוב של BGP.

• תכנן ניתוב היקף, כולל שרתי Proxy, חומות אש ושרתי Proxy בענן.

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

Create תוכנית עבור רוחב הפס הנדרש עבור כל עומס עבודה ראשי של Microsoft 365. מעריך בנפרד Exchange Online, SharePoint ודרישות Skype for Business רוחב הפס המקוון. באפשרותך להשתמש במחשבוני ההערכה שסיפקנו עבור Exchange Online ו- Skype for Business כנקודת התחלה; עם זאת, בדיקת ניסיון עם מדגם מייצג של פרופילי המשתמשים והמיקומים נדרשת כדי להבין באופן מלא את צרכי רוחב הפס של הארגון שלך.

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

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

דרישות רוחב הפס של התוכנית Skype for Business דרישות התעצבות, השהיה, עיכול וחדר ראש

Skype for Business Online כוללת גם דרישות רשת נוספות ספציפיות, המפורטות במאמר איכות מדיה וביצועי קישוריות רשת ב- Skype for Business Online.

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

תכנון דרישות זמינות גבוהה

Create תוכנית לזמינות גבוהה כדי לעמוד בצרכים שלך ולשלב אותה בדיאגרמת טופולוגיית הרשת המעודכנת שלך. קרא את הסעיף זמינות גבוהה והעברה לגיבוי בעת כשל באמצעות Azure ExpressRoute.

תכנון דרישות אבטחת הרשת

Create תוכנית לעמוד בדרישות אבטחת הרשת ולשלב אותה בדיאגרמת טופולוגיית הרשת המעודכנת שלך. קרא את הסעיף החלת פקדי אבטחה על תרחישי Azure ExpressRoute for Microsoft 365.

עיצוב קישוריות שירות יוצא

ל- ExpressRoute עבור Microsoft 365 יש דרישות רשת יוצאות שעשויות להיות לא מוכרות. באופן ספציפי, כתובות ה- IP המייצגות את המשתמשים והרשתות שלך ל- Microsoft 365 ופועלים כמקור נקודות הקצה עבור חיבורי רשת יוצאת אל Microsoft חייבות לפעול בהתאם לדרישות הספציפיות המתוארות להלן.

1. נקודות הקצה חייבות להיות כתובות IP ציבוריות הרשומות בחברה שלך או אצל ספק השירות המספקות לך קישוריות ExpressRoute.

2. יש לפרסם את נקודות הקצה ב- Microsoft ולאמת/לקבלן על-ידי ExpressRoute.

3. אין לפרסם את נקודות הקצה באינטרנט באמצעות אותו מדד ניתוב מועדף או יותר.

4. אין להשתמש ב נקודות הקצה לצורך קישוריות לשירותים של Microsoft שאינם מוגדרים באמצעות ExpressRoute.

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

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

קרא עוד אודות דרישות ExpressRoute NAT.

הוסף את השינויים עבור הקישוריות היוצאת לדיאגרמת טופולוגיית הרשת.

קישוריות שירות נכנס של עיצוב

רוב פריסות Microsoft 365 הארגוניות מבוססות על צורה מסוימת של קישוריות נכנסת מ- Microsoft 365 לשירותים מקומיים, כגון עבור תרחישים היברידיים של Exchange, SharePoint ו- Skype for Business, העברות תיבות דואר ואימות באמצעות תשתית ADFS. כאשר ExpressRoute מאפשר נתיב ניתוב נוסף בין הרשת המקומית שלך לבין Microsoft לקישוריות יוצאת, ייתכן שחיבורים נכנסים אלה יושפעו בטעות מניתוב אסימטרי, גם אם בכוונתך שזרימות אלה ימשיכו להשתמש באינטרנט. מומלץ להשתמש בכמה אמצעי זהירות המתוארים להלן כדי להבטיח שלא תהיה השפעה על זרימות אינטרנט המבוססות על זרימות נכנסות מ- Microsoft 365 למערכות מקומיות.

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

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

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

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

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

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

1. Microsoft 365 יכול לייעד רק נקודות קצה מקומיות המשתמשות בכתובות IP ציבוריות. משמעות הדבר היא כי גם אם נקודת הקצה הנכנסת המקומית חשופה רק ל- Microsoft 365 באמצעות ExpressRoute, עדיין צריכה להיות משויכת כתובת IP ציבורית.

2. כל זיהוי שמות ה- DNS שמבצעים שירותי Microsoft 365 כדי לפתור נקודות קצה מקומיות מתרחשות באמצעות DNS ציבורי. משמעות הדבר היא כי עליך לרשום את ה- FQDN של נקודות הקצה של השירות הנכנס למיפויי IP באינטרנט.

3. כדי לקבל חיבורי רשת נכנסים דרך ExpressRoute, יש לפרסם את רשתות המשנה הציבוריות של נקודות קצה אלה ב- Microsoft באמצעות ExpressRoute.

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

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

6. במקרה של מעגל ExpressRoute או מיקום meet-me לחוץ, יהיה עליך לוודא שנקודות הקצה הנכנסות המקומיות עדיין זמינות לקבל בקשות בנתיב רשת נפרד. משמעות הדבר עשויה להיות רשתות משנה של פרסום עבור נקודות קצה אלה באמצעות מעגלים מרובים של ExpressRoute.

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

8. שירותים מקומיים מסוימים, כגון Proxy של ADFS או גילוי אוטומטי של Exchange, עשויים לקבל בקשות נכנסות הן מהשירותים והן מהמשתמשים של Microsoft 365 מהאינטרנט. עבור בקשות אלה, Microsoft 365 ימקד את אותו FQDN כמו בקשות המשתמש דרך האינטרנט. מתן אפשרות לחיבורי משתמשים נכנסים מהאינטרנט לאותן נקודות קצה מקומיות, תוך אכיפת חיבורי Microsoft 365 להשתמש ב- ExpressRoute, מייצג מורכבות ניתוב משמעותית. עבור רוב הלקוחות המיישמים תרחישים מורכבים כאלה ב- ExpressRoute אינם מומלצים עקב שיקולים תפעוליים. תוקף נוסף זה כולל, ניהול סיכונים של ניתוב אסימטרי וידרוש ממך לנהל בקפידה פרסומות ומדיניות של ניתוב בממדים מרובים.

עדכן את תוכנית טופולוגיית הרשת שלך כדי להראות כיצד להימנע מנית ניתובים אסימטריים

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

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

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

2. השרתים במרכז הנתונים של ניו ג'רזי יכולים לראות נתיבי אינטרנט ו- ExpressRoute.

יש לנו גם הצעות כיצד לתקן אותן.

בעיה 1: ענן לחיבור מקומי דרך האינטרנט

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

1. הבקשה הנכנסת מ- Microsoft 365 מאחזרת את כתובת ה- IP של נקודת הקצה המקומית מ- DNS ציבורי ושולחת את הבקשה לרשת ההיקף שלך.

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

• השרת ברשת שלך מנתב את תעבורת ההחזרה אל Microsoft 365 באמצעות כל חיבור רשת זמין של ExpressRoute.

• התוצאה היא נתיב אסימטרי עבור זרימה זו ל- Microsoft 365, והתוצאה היא חיבור מנותק.

פתרון 1א:מקור NAT

פשוט הוספת NAT מקור לבקשה הנכנסת פותרת רשת זו שתצורתה שגויה. בדיאגרמה זו:

1. הבקשה הנכנסת ממשיכה להיכנס דרך רשת ההיקף של מרכז הנתונים של ניו ג'רזי. הפעם NAT מקור זמין.

2. התגובה מהשרת מנותב בחזרה לכיוון ה- IP המשויך ל- NAT המקור במקום לכתובת ה- IP המקורית, והתוצאה היא התגובה חוזרת לאורך אותו נתיב רשת.

פתרון 1b: הגדרת טווח נתיב

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

1. הבקשה הנכנסת ממשיכה להיכנס דרך רשת ההיקף של מרכז הנתונים של ניו ג'רזי. הפעם הקידומות שפרסומות מ- Microsoft באמצעות מעגל ExpressRoute אינן זמינות למרכז הנתונים של ניו ג'רזי.

2. התגובה מהשרת מנותב בחזרה לכיוון ה- IP המשויך לכתובת ה- IP המקורית בנתיב היחיד הזמין, והתוצאה היא התגובה חוזרת לאורך אותו נתיב רשת.

בעיה 2: ענן לחיבור מקומי באמצעות ExpressRoute

הדיאגרמה הבאה ממחישה את נתיב הרשת האסימטרי שבוצע כאשר תצורת הרשת שלך אינה מספקת NAT עבור בקשות נכנסות מהענן של Microsoft דרך ExpressRoute.

1. הבקשה הנכנסת מ- Microsoft 365 מאחזרת את כתובת ה- IP מ- DNS ושולחת את הבקשה לרשת ההיקפית שלך.

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

• המחשב ברשת שלך מנתב את תעבורת ההחזרה אל Microsoft 365 באמצעות כל חיבור רשת זמין של ExpressRoute.

• התוצאה היא חיבור אסימטרי ל- Microsoft 365.

פתרון 2: NAT מקור

פשוט הוספת NAT מקור לבקשה הנכנסת פותרת רשת זו שתצורתה שגויה. בדיאגרמה זו:

1. הבקשה הנכנסת ממשיכה להיכנס דרך רשת ההיקף של מרכז הנתונים של ניו יורק. הפעם NAT מקור זמין.

2. התגובה מהשרת מנותב בחזרה לכיוון ה- IP המשויך ל- NAT המקור במקום לכתובת ה- IP המקורית, והתוצאה היא התגובה חוזרת לאורך אותו נתיב רשת.

הנייר מוודא שעיצוב הרשת כולל את הסימטריה של הנתיב

בשלב זה, עליך לוודא על נייר שתוכנית היישום שלך מציעה סימטריית ניתוב עבור התרחישים השונים שבהם אתה משתמש ב- Microsoft 365. תזהה את נתיב הרשת הספציפי שצפוי להילקח כאשר אדם משתמש בתכונות שונות של השירות. מהרשת המקומית וניתוב WAN, להתקני ההיקף, לנתיב הקישוריות; ExpressRoute או האינטרנט, ולחיבור אל נקודת הקצה המקוונת.

תצטרך לעשות זאת עבור כל שירותי הרשת של Microsoft 365 שזוהו בעבר כהשירותים שהארגון שלך יאמץ.

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

תצורת קישוריות לקוח עיצוב

אם אתה משתמש בשרת Proxy עבור תעבורה מאוגדת באינטרנט, עליך להתאים את כל קבצי התצורה של PAC או הלקוח כדי להבטיח שתצורת מחשבי הלקוח ברשת שלך נקבעה כראוי לשליחת תעבורת ExpressRoute הרצויה ל- Microsoft 365 מבלי להעביר את שרת ה- Proxy, והתעבורה הנותרת, כולל חלק מהתעבורה של Microsoft 365, תישלח אל ה- Proxy הרלוונטי. קרא את המדריך שלנו בנושא ניהול נקודות קצה של Microsoft 365, לדוגמה, קבצי PAC.

הערה

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

מוודאים את הסימטריה של הנתיב

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

בין אם אתה יוזם חיבור ל- Microsoft 365 דרך האינטרנט או דרך ExpressRoute, המקור חייב להיות כתובת הניתנת לניתוב ציבורי. כאשר לקוחות רבים עמיתים ישירות באמצעות Microsoft, כתובות פרטיות שבהן שכפול אפשרי בין לקוחות אינו ניתן.

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

• שירותי SMTP כגון דואר Exchange Online של דייר מקומי למארח מקומי או לדואר SharePoint שנשלח מ- SharePoint למארח מקומי. פרוטוקול SMTP נמצא בשימוש נרחב יותר ברשת של Microsoft בהשוואה לקידומות הניתוב המשותפות באמצעות מעגלי ExpressRoute ופרסום שרתי SMTP מקומיים באמצעות ExpressRoute עשויות לגרום לכשלים בשירותים אחרים אלה.

• ADFS במהלך אימות סיסמה לכניסה.

• Exchange Server היברידיות.

• חיפוש משולב מאוחד של SharePoint.

• SharePoint hybrid BCS.

• Skype for Business ו/או Skype for Business הפדרציה.

• Skype for Business Cloud Connector.

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

1. אל תפרסם את אותה קידומת ניתוב של כתובת IP ציבורית לאינטרנט הציבורי ודרך ExpressRoute. מומלץ שהפרסומות של קידומת ניתוב BGP של IP ל- Microsoft דרך ExpressRoute הן מטווח שאינו פורסם לאינטרנט כלל. אם לא ניתן להשיג זאת עקב שטח כתובות ה- IP הזמין, חשוב לוודא שאתה מפרסם טווח ספציפי יותר ב- ExpressRoute מאשר כל מעגל אינטרנט.

2. השתמש באגרות IP נפרדות של NAT לכל מעגל ExpressRoute והפרד בין מעגלי האינטרנט שלך.

3. כל מסלול שפורסם ב- Microsoft ימשוך תעבורת רשת מכל שרת ברשת של Microsoft, ולא רק מהשרתים שעבורם נתיבים מתפרסמים לרשת שלך דרך ExpressRoute. רק פרסם נתיבים לשרתים שבהם תרחישי ניתוב מוגדרים ומובנים היטב על-ידי הצוות שלך. פרסם קידומות ניתוב נפרדות של כתובות IP בכל אחד ממעגלי ExpressRoute מרובים מהרשת שלך.

זמינות גבוהה והעברה לגיבוי בעת כשל עם Azure ExpressRoute

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

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

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

מחוץ לרשת שלך, Microsoft 365, ExpressRoute וספק ExpressRoute שלך כוללים רמות זמינות שונות.

זמינות שירות

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

• ExpressRoute מספק הסכם הסכם שירות (SLA) עם זמינות של 99.9% במעגלים ייעודיים בודדים בין Microsoft Network Edge לבין ספק ExpressRoute או תשתית השותפים. רמות שירות אלה מוחלות ברמת המעגל של ExpressRoute, המורכבת משני חיבורים הדדיים בלתי תלויים בין הציוד היתיר של Microsoft לבין ציוד ספק הרשת בכל מיקום עמית.

זמינות ספק

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

עיצוב תוכנית הזמינות שלך

מומלץ מאוד לתכנן ולעצב זמינות וגמישות גבוהה בתרחישי קישוריות מקצה לקצה עבור Microsoft 365. עיצוב צריך לכלול;

• אין נקודות כשל בודדות, כולל מעגלי אינטרנט ומעגלי ExpressRoute.

• מזעור מספר האנשים המושפעים ומשך הזמן של אותה השפעה עבור מצבי הכישלון הצפויים ביותר.

• מיטוב לתהליך שחזור פשוט, ניתן להפעלה חוזרת וטומטית ממצבי הכשל הצפויים ביותר.

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

תרחישי הקישוריות שלך צריכים לכלול טופולוגיית רשת הממוטבת עבור נתיבי רשת בלתי תלויים ופעילים מרובים ל- Microsoft 365. פעולה זו תניב זמינות טובה יותר מקצה לקצה מאשר טופולוגיה הממוטבת רק עבור יתירות ברמת המכשיר או הציוד הבודדים.

עצה

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

אנו ממליצים להקצות לפחות שני מעגלים של ExpressRoute עם כל מעגל מתחבר באמצעות מיקום אחר של עמית גיאוגרפי. עליך להקצות צמד מעגלים פעיל זה עבור כל אזור שבו אנשים ישתמשו בקישוריות ExpressRoute עבור שירותי Microsoft 365. הדבר מאפשר לכל אזור להישאר מחובר במהלך אסון המשפיע על מיקום מרכזי כגון מרכז נתונים או מיקום עמית. קביעת התצורה שלהם כפעילות/פעילה מאפשרת להפיץ תעבורת משתמשי קצה על-פני נתיבי רשת מרובים. פעולה זו מפחיתה את היקף האנשים המושפעים במהלך הפסקות חשמל של ציוד המכשיר או הרשת.

איננו ממליצים להשתמש במעגל ExpressRoute יחיד עם האינטרנט כגיבוי.

דוגמה: מעבר לגיבוי בעת כשל וזמינות גבוהה

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

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

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

תצורת הרשת ב- Contoso מבוססת על כמה עקרונות עיקריים:

• בכל אזור גיאוגרפי, קיימים מעגלים מרובים של Azure ExpressRoute.

• כל מעגל בתוך אזור יכול לתמוך בכל תעבורת הרשת בתוך אזור זה.

• הניתוב יעדיף בבירור נתיב אחד או אחר בהתאם לזמינות, למיקום וכן הלאה.

• מעבר לגיבוי בעת כשל בין מעגלי Azure ExpressRoute מתבצע באופן אוטומטי ללא קביעת תצורה או פעולה נוספת הנדרשת על-ידי Contoso.

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

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

אם ל- Contoso לא היתה אפשרות לכלול מעגלים מרובים של Azure ExpressRoute לכל אזור, ניתוב תעבורה שמקורו בצפון אמריקה למעגל Azure ExpressRoute באסיה האוקיינוס השקט יוסיף רמת השהיה לא קבילה ותצורות העברה נדרשות של DNS מוסיפה מורכבות.

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

עדיין יש לך שאלות לגבי תכנון והטמעה של ניהול תעבורה או Azure ExpressRoute? קרא את שאר הנחיות הרשת והביצועים שלנו או את השאלות הנפוצות של Azure ExpressRoute.

החלת פקדי אבטחה על תרחישי Azure ExpressRoute עבור Microsoft 365

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

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

אפשרות שילוב ExpressRoute	מודל היקף אבטחת רשת
החלפה בענן מעוגלת	התקן תשתית אבטחה/היקף קיימת או השתמש בה במתקן המיקום המשותפים שבו נוצר החיבור של ExpressRoute. השתמש במתקן המיקום המשותפים אך ורק למטרות ניתוב/חיבור הדדי וגרירות לאחור של חיבורים ממתקן המיקום המשותפים אל תשתית האבטחה/היקף המקומית.
Ethernet של נקודה לנקודה	סיים את החיבור של Point-to-Point ExpressRoute במיקום הקיים של תשתית אבטחה/היקף מקומית. התקן תשתית אבטחה/היקף חדשה ספציפית לנתיב של ExpressRoute ולסיום החיבור של Point-to-Point שם.
IPVPN מסוג 'כל לכל'	השתמש בתשתית אבטחה/היקף מקומית קיימת בכל המיקומים שהיציאה לתוך IPVPN המשמשת לקישוריות ExpressRoute for Microsoft 365. הצמדת ה- IPVPN המשמש עבור ExpressRoute עבור Microsoft 365 למיקומים מקומיים ספציפיים המיועדים לשמש כאבטחה/היקף.

ספקי שירות מסוימים מציעים גם פונקציונליות אבטחה/היקף מנוהלת כחלק מפתרונות השילוב שלהם עם Azure ExpressRoute.

כאשר אתה שוקל את מיקום הטופולוגיה של אפשרויות היקף הרשת/האבטחה המשמשות עבור חיבורי ExpressRoute עבור Microsoft 365, להלן שיקולים נוספים

• פקדי הרשת/האבטחה של העומק והסוג עשויים להשפיע על הביצועים ועל המדרגיות של חוויית המשתמש של Microsoft 365.

• זרימות יוצאות (מקומיות של> Microsoft) ותעבורה נכנסת (Microsoft-on-premises>) [אם זמין] עשויות לכלול דרישות שונות. ייתכן שהם שונים מיעדים יוצאים ליעדי אינטרנט כלליים.

• דרישות Microsoft 365 עבור יציאות/פרוטוקולים ו רשתות משנה של IP נחוצה זהות, בין אם התעבורה מנותב דרך ExpressRoute עבור Microsoft 365 או דרך האינטרנט.

• המיקום הטופולוגי של בקרות הרשת/האבטחה של הלקוחות קובע את רשת הקצה-קצה האולטימטיבית בין המשתמש לשירות Microsoft 365, ויכולה להשפיע באופן משמעותי על ההשהיה והצפיפות ברשת.

• אנו ממליצים ללקוחות לעצב את טופולוגיית האבטחה/היקף שלהם לשימוש עם ExpressRoute for Microsoft 365 בהתאם לשיטות העבודה המומלצות עבור יתירות, זמינות גבוהה ושחזור מאסונות.

להלן דוגמה של Contoso המשווה בין אפשרויות הקישוריות השונות של Azure ExpressRoute למודלים של אבטחת היקף המפורטים לעיל.

דוגמה: Securing Azure ExpressRoute

Contoso שוקלת ליישם את Azure ExpressRoute ולאחר תכנון הארכיטקטורה האופטימלית עבור ExpressRoute עבור Microsoft 365 ולאחר השימוש בהדרכה לעיל כדי להבין את דרישות רוחב הפס, הם בודקים את השיטה הטובה ביותר לאבטחת ההיקף שלהם.

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

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

תכנון רוחב פס עבור Azure ExpressRoute

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

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

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

לאחר שיש לך תוכנית בסיסית משוערת הכוללת את כל יישומי הרשת, נסה את Microsoft 365 עם קבוצה קטנה המרכיבה את הפרופילים השונים של אנשים בארגון שלך כדי לקבוע את השימוש בפועל, והשתמש בשתי המידות כדי להעריך את כמות רוחב הפס שתדרוש עבור כל מיקום משרד. אם נמצאו בעיות השהיה או עיכול של TCP בבדיקה, ייתכן שתצטרך לקרב את היציאה לאנשים המשתמשים ב- Microsoft 365 או להסיר סריקת רשת אינטנסיבית, כגון פענוח/בדיקה של SSL.

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

בניית הליכי הפריסה והבדיקה

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

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

2. תכנן לבדוק נתיבים באמצעות traceroute ו- TCP להתחבר ממארח מחובר לאינטרנט נפרד.

3. רצוי לבצע בדיקות של שירותים נכנסים ויציאה ברשת בדיקה מבודדת עם דייר בדיקה של Microsoft 365.

   • לחלופין, ניתן לבצע בדיקות ברשת ייצור אם הלקוח עדיין אינו משתמש ב- Microsoft 365 או שהוא בפריסת ניסיון.

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

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

בניית הליכי הפריסה שלך

פרוצדורות הפריסה שלך אמורות לפרס לקבוצות קטנות של אנשים בשלבים כדי לאפשר בדיקות לפני הפריסה לקבוצות גדולות יותר של אנשים. להלן כמה דרכים לשלב הפריסה של ExpressRoute.

1. הגדר את ExpressRoute עם עמית-לעמית של Microsoft והעבר את מודעות הנתיב למארח יחיד למטרות בדיקה בשלבים בלבד.

2. פרסם נתיבים לרשת ExpressRoute למקטע רשת אחד בהתחלה והרחב פרסומות מסלול לפי מקטע רשת או אזור.

3. אם אתה פורס את Microsoft 365 בפעם הראשונה, השתמש בפריסת רשת ExpressRoute כפריט ניסיון עבור כמה אנשים.

4. אם אתה משתמש בשרתי Proxy, באפשרותך לחילופין לקבוע תצורה של קובץ PAC לבדיקה כדי להפנות כמה אנשים ל- ExpressRoute עם בדיקות ומשוב לפני שתוסיף עוד.

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

• עדכון רשומות SPF TXT אם שינית כתובות IP עבור שרתים מקומיים ימשיכו לשלוח דואר אלקטרוני.

• עדכון ערכי DNS עבור שרתים מקומיים אם שינית כתובות IP כדי להתאים לתצורות NAT חדשות.

• ודא שנרשמת כמנוי להזנת ה- RSS עבור הודעות נקודת קצה של Microsoft 365 כדי לשמור על כל ניתוב או תצורות Proxy.

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

בנה את הליכי הבדיקה שלך

הליכי הבדיקה שלך צריכים לכלול בדיקות עבור כל שירות רשת יוצאת ותעבורה עבור Microsoft 365, שישתמש ב- ExpressRoute ובשירותים שלא ישתמשו בהם. ההליכים צריכים לכלול בדיקות מכל מיקום רשת ייחודי, כולל משתמשים שאינם מקומיים ב- LAN הארגוני.

להלן כמה דוגמאות לפעילויות בדיקה.

1. איתות (Ping) מהנתב המקומי לנתב מפעיל הרשת.

2. ודא שמודעות כתובת ה- IP של Microsoft 365 ומעלה ו- CRM Online מתקבלות על-ידי הנתב המקומי.

3. ודא ש- NAT הנכנס והיכנס פועל בין ExpressRoute לרשת הפנימית.

4. ודא שהנתיבים ל- NAT שלך מתפרסמים מהנתב.

5. ודא ש- ExpressRoute קיבל את הקידומות שפרסמת.

   • השתמש ב- cmdlet הבא כדי לאמת פרסומות של עמיתים:

   Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
   

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

7. מעגלי ExpressRoute מקושרים, מאמתים ששני הפעלות BGP פועלות.

8. הגדר מארח יחיד בחלק הפנימי של ה- NAT והשתמש ב- Ping, tracert ו- tcpping כדי לבדוק את הקישוריות במעגל החדש אל המחשב המארח outlook.office365.com. לחלופין, באפשרותך להשתמש בכלי כגון Wireshark או Microsoft Network Monitor 3.4 ביציאה משוקפת ל- MSEE כדי לאמת את היכולת להתחבר לכתובת ה- IP המשויכת ל- outlook.office365.com.

9. בדוק פונקציונליות ברמת היישום עבור Exchange Online.

• בדוק של- Outlook יש אפשרות להתחבר Exchange Online דואר אלקטרוני של שליחה/קבלה.

• בדיקה של Outlook יש אפשרות להשתמש במצב מקוון.

• בדוק את קישוריות הטלפון החכם ויכולת שליחה/קבלה.

10. בדיקת פונקציונליות ברמת היישום עבור SharePoint

• בדוק OneDrive for Business הסינכרון.

• בדוק את הגישה לאינטרנט של SharePoint.

11. בדוק פונקציונליות ברמת היישום עבור Skype for Business השיחות הבאים:

• הצטרף לשיחת ועידה כמשתמש מאומת [הזמנה שהותחלה על-ידי משתמש קצה].

• הזמן משתמש לשיחת ועידה [הזמנה שנשלחה מ- MCU].

• הצטרף לשיחת ועידה כמשתמש אנונימי באמצעות יישום האינטרנט Skype for Business שלך.

• הצטרף לשיחה מחיבור המחשב הקווי, מטלפון ה- IP ומהמכשיר הנייד שלך.

• קריאה למשתמש מאוחד o שיחה לאימות PSTN: השיחה הושלמה, איכות השיחה מקובלת, זמן החיבור מקובל.

• ודא שמצב הנוכחות עבור אנשי קשר מתעדכן הן עבור חברי הדייר והן עבור משתמשים מאוחדים.

בעיות נפוצות

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

• שימוש בטופולוגיית ניתוב רשת פתוחה או שטוחה ללא מקור NAT במקום.

• לא משתמש ב- SNAT כדי לנתב לשירותים נכנסים הן דרך חיבורי האינטרנט והן דרך חיבורי ExpressRoute.

• לא בודקים שירותים נכנסים ב- ExpressRoute ברשת בדיקה לפני הפריסה רחבה.

פריסת קישוריות ExpressRoute דרך הרשת שלך

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

תחילה למבחן שלך ולאחר מכן לייצור:

• הפעל את שלבי הפריסה כדי להפוך את ExpressRoute לזמין.

• בדוק אם אתה רואה את נתיבי הרשת כצפוי.

• בצע בדיקות בכל שירות נכנס ותעבורה יוצאת.

• חזור למצב קודם אם תתגלה בעיות כלשהן.

הגדרת חיבור בדיקה ל- ExpressRoute באמצעות מקטע רשת לבדיקה

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

ביצוע תוכניות הפריסה והבדיקה

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

• רשימה של שירותים יוצאים ושירותים נכנסים המעורבים בשינוי הרשת.

• דיאגרמה של ארכיטקטורת רשת גלובלית המציגה הן יציאה מהאינטרנט והן את מיקומי ההיכרות של ExpressRoute.

• דיאגרמת ניתוב רשת המדגימה את נתיבי הרשת השונים המשמשים עבור כל שירות שנפרס.

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

• תוכנית בדיקה לבדיקת כל שירות של Microsoft 365 ורשת.

• אימות נייר הושלם של נתיבי ייצור עבור שירותים נכנסים ו יוצאים.

• בדיקה שהושלמה במקטע רשת בדיקה כולל בדיקת זמינות.

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

זהירות

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

קביעת תצורה של QoS Skype for Business Online

QoS נדרש כדי לקבל את יתרונות הקול והפגישות עבור Skype for Business Online. באפשרותך לקבוע את התצורה של QoS לאחר שתבטיח שחיבור הרשת של ExpressRoute אינו חוסם אף אחת מהגישה האחרות שלך לשירות Microsoft 365. התצורה של QoS מתוארת במאמר ExpressRoute ו- QoS ב- Skype for Business Online.

פתרון בעיות ביישום שלך

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

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

הפעל PSPing עם מעקב רשת לכל נקודת קצה של לקוח והערך את כתובות ה- IP של המקור והיעד כדי לאמת שהן כצפוי. הפעל את telnet לכל מארח דואר שאתה חושף ביציאה 25 וודא ש- SNAT מסתיר את כתובת ה- IP המקורית של המקור אם הדבר צפוי.

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

הנה קישור קצר שתוכל להשתמש בו כדי לחזור: https://aka.ms/implementexpressroute365

נושאים קשורים

הערכת קישוריות רשת של Microsoft 365

Azure ExpressRoute for Microsoft 365

ביצועי איכות מדיה וקישוריות רשת ב- Skype for Business Online

מיטוב הרשת שלך עבור Skype for Business Online

ExpressRoute ו- QoS ב- Skype for Business Online

זרימת שיחה באמצעות ExpressRoute

כוונון הביצועים של Microsoft 365 באמצעות ביצועי בסיס והיסטוריית ביצועים

תוכנית לפתרון בעיות ביצועים עבור Microsoft 365

כתובות URL וטווחי כתובות IP של Microsoft 365

כוונון רשת וביצועים של Microsoft 365