אין להשתמש ב'איכות השירות (QoS)' ל-Google Meet ברשת שלכם כי מערכת Meet מתאימה את עצמה באופן אוטומטי לתנאי הרשת. כדאי להשתמש ב-QoS רק אם יש לכם סיבה טובה לכך, למשל רשת עמוסה, ואם אתם יכולים לפרוס ולתחזק מודל QoS מקצה לקצה ברשת.
אם אתם חייבים להשתמש ב-QoS
אם הרשת שלכם עמוסה ואתם צריכים להבטיח איכות שירות מסוימת ל-Meet, אתם יכולים לבחור באחת מהאפשרויות הבאות:
- הוספת QoS ללקוחות Meet.
- הוספת QoS בקצה הרשת.
אפשרות 1: הוספת QoS ללקוחות Meet
אם מוסיפים QoS ללקוחות Meet, תעבורת הנתונים של Meet מתויגת במכונות הלקוח לצורך QoS ברשת הארגונית. תגי ה-QoS מוסרים כשהתעבורה נשלחת לאינטרנט. תנועה נכנסת מ-Meet מתויגת כשהיא נכנסת לרשת הארגונית.
כדי להוסיף QoS ללקוחות Meet:
- מגדירים סימון DSCP באמצעות מדיניות QoS של Windows במסוף Group Policy Management.
- מזהים את תעבורת הנתונים ב-Meet באמצעות טווח היציאות של Meet, כפי שמתואר במאמר איך מכינים את הרשת לפגישות ב-Meet.
- מסירים את התיוג של DSCP לתנועה שיוצאת מהשער הפנימי לאינטרנט.
- תיוג תנועה ב-Meet שהתקבלה מהאינטרנט. תעבורת האינטרנט הזו היא תעבורת נתונים של פרוטוקול להעברה בזמן אמת או פרוטוקול לבקרה של העברה בזמן אמת (RTP/RTCP) שמשתמשת בטווח היציאות של Meet.
אפשרות 2: הוספת QoS בקצה הרשת
באפשרות הזו, תעבורת הנתונים של לקוחות Meet מתויגת בקצה הרשת לצורך QoS ברשת הארגונית. תגי ה-QoS מוסרים כשהתעבורה נשלחת לאינטרנט. תנועה נכנסת מ-Meet מתויגת כשהיא נכנסת לרשת הארגונית.
כדי להוסיף QoS בקצה הרשת:
- בכל קצוות הרשת, מוסיפים כלל לסימון התנועה ב-Meet. כדי להבטיח השהיה נמוכה ושינוי נמוך בזמן ההגעה של מנות הנתונים, צריך להקצות את המחלקה Expedited Forward (EF) לתנועה ב-Meet. התנועה הזו היא תנועת RTP/RTCP שמשתמשת בטווחי היציאות של Meet.
- מסירים את התיוג של DSCP לתנועה שיוצאת מהשער הפנימי לאינטרנט.
- תיוג התנועה ב-Meet שמתקבלת מהאינטרנט באמצעות המחלקה EF. התנועה הזו היא תנועת RTP/RTCP שמשתמשת בטווחי היציאות של Meet.
- כדי להשיג ערכים נמוכים של עיכוב, שינוי בזמן ההגעה (Jitter) ואובדן נתונים, צריך לתת עדיפות לתנועת נתונים מסוג EF בחברה שלכם ולמקם אותה בתורים עם חביון נמוך או בתורים עם עדיפות מחמירה. כדי לוודא שהתנועה מסוג EF לא תגביל סוגי תנועה אחרים ברשת, כדאי להטמיע אמצעי זהירות נוספים, כמו הגבלת קצב מעל ערכי רוחב הפס שהוגדרו מראש.
בדיקת QoS
לספקי חומרה שונים יש הטמעות שונות של QoS, ולכן יכולים להיות הבדלים קלים בבדיקות. כוונון עדין כדי להבטיח QoS מקצה לקצה.
- כדאי להתחיל בסביבת בדיקה קטנה כדי לבדוק את הביצועים של מכשיר יחיד.
- עוקבים אחרי הנתיב של החבילות דרך מכשירי הרשת השונים כדי לוודא שנתיב הרשת מכבד את הסימונים של הלקוח, ומבינים את הנפילות של התורים ואת קצב העברת הנתונים במכשירים.
- בהמשך הדף מפורטים קטעים נוספים לבדיקה של QoS.
יכול להיות שמכשירים מסוימים ברשת שלא מבוססים על טכנולוגיה חכמה, כמו רכזת או מתג פשוט, לא יתמכו בתכונת ה-QoS המלאה. מוודאים שערך ה-DSCP שסומן במכשיר במעלה הזרם לא משתנה. כך, המכשירים החכמים במורד הזרם יכולים להחיל את אסטרטגיית ה-QoS הנכונה על סמך הסימון הנכון.
איך מוודאים שנתיב הרשת מכבד את הסימונים של הלקוח
כדי לוודא שסימון ה-DSCP נכון, אפשר להשתמש בכלים הבאים:
- האזנה לחבילות נתונים – אפשר להשתמש בהאזנה לחבילות נתונים באמצעות Wireshark, למשל, כדי לוודא שסימוני ה-DSCP נכונים גם במכשיר הרשת (AP, נתב או מתג) וגם במכשיר הקצה (מחשב). משתמשים בשיקוף יציאות או בכלי לניתוח יציאות במתג (SPAN) כדי לשלוח נתונים שנאספו ליציאת יעד שנבחרה לצורך שיקוף יציאות מקומי. פרוטוקול של יציאה מרוחקת, כמו RSPAN (מנתח יציאות מרוחקות של מתג), יכול לשלוח נתונים שנתפסו לשרת מרוחק לצורך ניתוח.
- NetFlow – אפשר להשתמש ב-NetFlow כדי לאמת את סימון ה-DSCP במכשיר הרשת. ערך ה-DSCP מיוצא כברירת מחדל אל האוסף. מסננים את ה-5-tuple (כתובת IP, פרוטוקולים ויציאות) מהנתונים שנאספו כדי לאמת את ערך ה-DSCP לכל אפליקציה ספציפית.
מעקב אחרי ביצועי איכות השירות של Meet ברמת הרשת
להשתמש בכלי בקרה שמבוסס על Simple Network Management Protocol (SNMP) כדי להציג את התצוגה של מגמות השימוש בתורים שונים ושיעורי הנטישה של תורים. אם תסמנו את Meet ברמת האפליקציה כ-EF, תוכלו לבדוק את השימוש ב-EF ואת שיעור הנטישה של המחלקה הזו כדי להבין את הביצועים של Meet בממשק ברשת.
על ידי צבירת נתוני האפליקציה, NetFlow יכול להציג תצוגה מוערמת של תצוגה ספציפית לאתר או תצוגה גלובלית.
סימולציה של עומס ואימות של QoS
- ליצור בסביבת הבדיקה כמה זרמי תנועה שחורגים מרוחב הפס המקסימלי של המדיה. לדוגמה, ליצור תנועה של 2 Gbps בנתיב של 1 Gbps.
- משווים את קצב העברת הנתונים בנקודת הקצה המקבלת כדי לוודא שעומס תנועה בעדיפות גבוהה מקבל טיפול הולם.
כדי לדמות עומס ברשתות אלחוטיות:
- ליצור כמה תהליכים לאותה נקודת גישה. לדוגמה, ב-802.11n, שולחים 2 על 150 מגה-ביט לשנייה לכל זרימה, כי 802.11n יכול לתמוך ברוח פס מקסימלית של כ-180 מגה-ביט לשנייה.
- בודקים את קצב העברת הנתונים בנקודת הקצה המקבלת.
לדוגמה, כדי להוכיח שתנועה בעדיפות גבוהה מקבלת שירות טוב יותר, שולחים סוג אחר של תנועה דרך Wi-Fi (באותה נקודת גישה, באותו תחום התנגשות). תנועה בעדיפות גבוהה צריכה לקבל את כל נפח התפוקה בלי ירידה, בעוד שתנועה בעדיפות נמוכה צריכה לרדת באופן משמעותי.
כדי לבדוק שה-QoS פועל כצפוי, מזינים את הפקודות הבאות:
- כדי לבצע בדיקה מיטבית, מזינים את הפקודה iperf3 -c IP address -u -b 150m -t 50 -l 1000B -i 10 -S 0x0.
- בשביל EF, מזינים iperf3 -c כתובת IP -u -b 150m -t 50 -l 1000B -i 10 -S 0xB8.
Google, Google Workspace וסימנים וסמלי לוגו קשורים הם סימנים מסחריים של Google LLC. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.