אין להשתמש ב'איכות השירות (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 במסוף לניהול מדיניות קבוצתית.
- מזהים את התעבורה ב-Meet באמצעות טווח היציאות של Meet, כפי שמתואר במאמר איך מכינים את הרשת לפגישות ב-Meet.
- מסירים את התיוג של DSCP לתנועה שיוצאת מהשער הפנימי לאינטרנט.
- תיוג תעבורת נתונים ב-Meet שמתקבלת מהאינטרנט. תעבורת הנתונים הזו באינטרנט היא תעבורת נתונים של פרוטוקול להעברה בזמן אמת או פרוטוקול בקרה להעברה בזמן אמת (RTP/RTCP) שמשתמשת בטווחים של יציאות Meet.
אפשרות 2: הוספת QoS בקצה הרשת
באפשרות הזו, תעבורת הנתונים של לקוחות Meet מתויגת בקצה הרשת לצורך QoS ברשת הארגונית. תגי ה-QoS מוסרים כשתעבורת הנתונים נשלחת לאינטרנט. תעבורת נתונים נכנסת של Meet מתויגת כשהיא נכנסת לרשת הארגונית.
כדי להוסיף QoS בקצה הרשת:
- בכל קצוות הרשת, מוסיפים כלל לסימון התנועה ב-Meet. כדי להבטיח השהיה נמוכה ושינויים קלים בזמן ההגעה של מנות הנתונים (Jitter), צריך להקצות את המחלקה Expedited Forward (EF) לתנועה ב-Meet. התנועה הזו היא תנועת RTP/RTCP שמשתמשת בטווחי היציאות של Meet.
- מסירים את התיוג של DSCP לתנועה שיוצאת מהשער הפנימי לאינטרנט.
- תיוג תעבורת נתונים של Meet שמתקבלת מהאינטרנט באמצעות מחלקת ה-EF. תעבורת הנתונים הזו היא תעבורת הנתונים של RTP/RTCP שמשתמשת בטווחי היציאות של Meet.
- כדי להשיג ערכים נמוכים של עיכוב, שינוי בזמן ההגעה (Jitter) ואובדן נתונים, צריך לתת עדיפות לתנועת נתונים מסוג EF בחברה שלכם ולמקם אותה בתורים עם עדיפות גבוהה או בתורים עם עדיפות קפדנית. כדי לוודא שתעבורת הנתונים של EF לא מגבילה סוגי תעבורת נתונים אחרים ברשת, צריך להטמיע אמצעי זהירות נוספים, כמו הגבלת קצב של יצירת בקשות מעל ערכי רוחב פס מוגדרים מראש.
בדיקת QoS
לספקי חומרה שונים יש הטמעות שונות של QoS, ולכן יכולים להיות הבדלים קלים בבדיקות. כוונון עדין כדי להבטיח QoS מקצה לקצה.
- כדאי להתחיל עם סביבת בדיקה קטנה כדי לבדוק את הביצועים של מכשיר אחד.
- עוקבים אחרי הנתיב של החבילות דרך מכשירי הרשת השונים כדי לוודא שנתיב הרשת מכבד את הסימונים של הלקוח, ומבינים את הנטישות של התורים ואת קצב העברת הנתונים במכשירים.
- כדי לבדוק ולבחון את איכות השירות, אפשר לעיין בקטעים הבאים בדף הזה.
יכול להיות שמכשירים מסוימים ברשת שלא כוללים יכולות חכמות, כמו רכזת או מתג ברמה נמוכה, לא יתמכו בתכונת ה-QoS המלאה. מוודאים שערך ה-DSCP שסומן במכשיר במעלה הזרם לא משתנה. כך, המכשירים החכמים בהמשך השרשרת יכולים להחיל את אסטרטגיית ה-QoS הנכונה על סמך הסימון הנכון.
איך מוודאים שהנתיב ברשת מכבד את הסימונים של הלקוח
כדי לוודא שסימון ה-DSCP נכון, אפשר להשתמש בכלים הבאים:
- Packet sniffing – אפשר להשתמש ב-packet sniffing עם Wireshark, למשל, כדי לוודא שסימוני ה-DSCP נכונים גם במכשיר הרשת (AP, נתב או מתג) וגם במכשיר הקצה (מחשב). אפשר להשתמש ב-port mirroring או ב-switch port analyzer (SPAN) כדי לשלוח נתונים שנתפסו ליציאת יעד שנבחרה לצורך port mirroring מקומי. פרוטוקול של יציאה מרוחקת, כמו remote switch port analyzer (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 -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. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.