‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת זמן מדויק למכונות U4 Compute Engine

בדף הזה מוסבר איך להגדיר זמן מדויק במכונה של Compute Engine ב-U4, ואיך להגדיר מעקב כדי שתוכלו לראות את הדיוק של סנכרון הזמן.

איך זה עובד

Google Cloud הפתרון Ultra Low Latency (ULL)‎ משתמש בפרוטוקול סנכרון השעון Firefly כדי לספק סנכרון ברמת הננו-שנייה. ‫Firefly מבצע את הפעולות הבאות באופן אוטומטי:

מבצע סנכרון פנימי כדי לסנכרן בין השעונים של ממשקי הרשת הפיזיים (NIC) של כל השרתים המארחים של מכונות U4.
מבצע סנכרון חיצוני כדי לסנכרן את השעונים של כרטיסי ה-NIC הפיזיים של כל שרתי המארחים של מופעי U4 עם הזמן האוניברסלי המתואם (UTC).

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

מידע נוסף על Firefly זמין ב Google Cloud פוסט בבלוג: הסבר על פרוטוקול סנכרון השעון של Firefly.

לפני שמתחילים

לפני שמגדירים שעה מדויקת למכונות U4 ב-Compute Engine, צריך לעמוד בדרישות הבאות.

יצירת מכונת U4

אם עוד לא עשיתם זאת, צרו מכונה של Compute Engine מסוג U4. בחרו את ההליך שמתאים לתרחיש לדוגמה שלכם:

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

מוודאים שלא פועלים שירותים אחרים לסנכרון השעון

בנהלים שבדף הזה נעשה שימוש ב-chrony כלקוח מומלץ לסינכרון השעון. לפני שמתחילים, ודאו שבמכונה לא פועלים שירותים אחרים לסנכרון השעון, כמו ntpd, ‏ systemd-timesyncd או phc2sys. אינטראקציות לא צפויות עם השירותים האלה עלולות לגרום לשגיאות בהגדרות של chrony.

בגרסה chrony 4.7 ואילך של chronyd, אפשר להריץ את הפקודה הבאה כדי לבדוק את יומן האזהרות לגבי שירותים אחרים של סנכרון השעון:

journalctl -u chronyd

אם פועל שירות אחר לסנכרון שעון, הפלט כולל הודעת אזהרה כמו: System clock interference detected (another NTP client?).

איך מקבלים את השמות של ממשקי הרשת

מקבלים את השמות של ממשקי הרשת הווירטואלית (vNIC) של המופע כפי שהוקצו על ידי מערכת ההפעלה של האורח. בזמן ש- Google Cloud משתמש בשמות כמו nic0 ו-nic1, הפורמט של השמות במערכת ההפעלה של האורח שונה, למשל enp22s0f0 ו-ens8f0.

כדי להציג את שמות ה-vNIC לפי הסדר, מריצים את הפקודה הבאה:

find /sys/class/net -type l -not -lname '*virtual*' -printf '%l %f\n' | sort | awk '{print $2}'

הגדרה של `chrony` כך שייטען רק אחרי שמנהלי ההתקנים של הרשת יציבים

במקרים מסוימים, יכול להיות ש-systemd יטען את chrony לפני שמנהלי ההתקנים של ממשק הרשת יסיימו את תהליך האיניציאליזציה. במצב כזה, יכול להיות ש-chrony לא יתחיל לפעול כי הוא לא יכול לבצע איניציאליזציה למכשיר PTP hardware clock (PHC)‎.

כדי למנוע את הבעיה שצוינה למעלה, צריך לבטל את ההגדרה של קובץ היחידה chrony של systemd כדי להמתין שמכשירי PHC יהיו מוכנים. לשם כך, פועלים לפי השלבים הבאים. אם אתם משתמשים ב-DPDK במכונה מסוג U4C, בחרו בכרטיסייה DPDK configuration.

הגדרה רגילה

מריצים את פקודת העריכה:
```
systemctl edit chronyd
```

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

במכונות U4P ו-U4C:

[Unit]
After=dev-ptp0.device dev-ptp1.device dev-ptp2.device
Requires=dev-ptp0.device dev-ptp1.device dev-ptp2.device

במקרים של מופעי U4S:

[Unit]
After=dev-ptp0.device
Requires=dev-ptp0.device

מפעילים מחדש את השירות. הפקודה systemctl edit שהרצתם קודם טענה מחדש באופן אוטומטי את ה-daemon, אבל מומלץ להריץ את הפקודה הבאה כדי לוודא ש-chrony פועל אחרי השינויים.
```
systemctl restart chronyd
```

הגדרת DPDK

אם אתם משתמשים ב-DPDK במכונת U4C, צריך לקבל את מספר האינדקס של מכשיר ה-PHC שמשויך ל-nic0.

מכיוון ש-DPDK מקשר את ממשקי הרשת של ULL (nic1 ו-nic2) למרחב הפעולה של המשתמש, nic0 הוא הממשק היחיד שחושף מכשיר PTP לליבה.

מריצים את הפקודה הבאה ומתעדים את הערך של PTP Hardware Clock:NUMBER כדי להשתמש בו בשלב מאוחר יותר.
```
ethtool -T NIC0
```
מחליפים את NIC0 בשם של ממשק nic0, למשל enp22s0f0.
מריצים את פקודת העריכה:
```
systemctl edit chronyd
```
מוסיפים את ההחרגה הבאה:
```
[Unit]
After=dev-ptpNUMBER.device
Requires=dev-ptpNUMBER.device
```
מחליפים את NUMBER במספר האינדקס של מכשיר ה-PHC שקיבלתם בשלב 1.
מפעילים מחדש את השירות. הפקודה systemctl edit שהרצתם קודם טענה מחדש את הדמון באופן אוטומטי, אבל מומלץ להריץ את הפקודה הבאה כדי לוודא ש-chrony פועל אחרי השינויים.
```
systemctl restart chronyd
```

הגדרת `chrony` לשימוש בשעון של כרטיס ה-NIC הפיזי שסונכרן עם Firefly

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

ממשקי הרשת הווירטואליים (vNIC) של מופע U4, כפי שמוצגים במערכת ההפעלה של האורח (למשל enp22s0f0), ממופים לממשקי רשת פיזיים בשרת המארח של המופע. כרטיס רשת וירטואלי נתון יכול לגשת לשעון של כרטיס הרשת הפיזי באמצעות מכשיר שעון החומרה של PTP‏ (PHC) התואם:

שמות מכשירי PHC ב-Linux הם בפורמט הבא: /dev/ptpNUMBER, כאשר NUMBER נקבע על ידי ליבת Linux בהתאם לסדר האתחול של המכשיר. לדוגמה, השמות הבאים של מכשירי PHC: ‏ /dev/ptp0, ‏ /dev/ptp1, ‏ /dev/ptp2.
כדי לציין שעון NIC פיזי כמקור לסנכרון, ההגדרה של chrony צריכה להשתמש במכשיר ה-PHC המתאים או לפתור אותו.

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

הגדרת chrony גרסה 4.7 ואילך במכונות U4P ו-U4C
הגדרת chrony בגרסה 4.6.1 ובגרסאות קודמות במכונות U4P ו-U4C
הגדרת chrony בגרסה 4.7 ואילך במכונות U4S

הגדרת `chrony` מגרסה 4.7 ואילך במכונות U4P ו-U4C

בגרסה 4.7 ואילך של chrony אפשר לציין שם של vNIC כמקור השעון, והוא יתורגם באופן אוטומטי למכשיר השעון של חומרת ה-PTP‏ (PHC) שמייצג את השעון הפיזי של ה-NIC.

הגדרה רגילה

כדי להגדיר את chrony בגרסה 4.7 ואילך במכונה של U4P או U4C:

מוסיפים את הטקסט הבא לקובץ התצורה chrony, /etc/chrony.conf. הקובץ צריך להכיל רק את ההגדרות הבאות. חשוב להסיר או להחליף את כל התוכן הקיים בקובץ.

# Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC NIC0:nocrossts poll -1 noselect
refclock PHC NIC1:nocrossts poll -1
refclock PHC NIC2:nocrossts poll -1 noselect

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC NIC0 poll -1 noselect
refclock PHC NIC1 poll -1 noselect
refclock PHC NIC2 poll -1 noselect

מחליפים את NIC0,‏ NIC1 ו-NIC2 בשמות המתאימים שקיבלתם קודם. אם צריך, אפשר לעיין במאמר בנושא קבלת שמות של ממשקי רשת.

כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:
```
systemctl restart chronyd
```

‫chrony מתעד ביומנים נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של NIC1 כמקור הזמן.

הגדרת DPDK

כדי להגדיר את chrony בגרסה 4.7 ואילך במכונה מסוג U4C שמשתמשת ב-DPDK:

מוסיפים את הטקסט הבא לקובץ התצורה chrony, /etc/chrony.conf. הקובץ צריך להכיל רק את ההגדרות הבאות. חשוב לוודא שמסירים או מחליפים את כל התוכן הקיים בקובץ.

# Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure the nic0 interface clock for tracking and select it as the source.
refclock PHC NIC0:nocrossts poll -1

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC NIC0 poll -1 noselect

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

כדי להחיל את ההגדרה, מפעילים מחדש את chrony באמצעות הפקודה הבאה:
```
systemctl restart chronyd
```

‫chrony מתעד ביומן את הנתונים הסטטיסטיים של סנכרון השעון ב-/var/log/chrony/tracking.log, באמצעות השעון של חומרת ה-PTP של NIC0 כמקור הזמן.

הגדרת `chrony` בגרסה 4.6.1 ומטה במכונות U4P ו-U4C

בגרסאות 4.6.1 ומטה של chrony, צריך לציין באופן ידני את שם המכשיר של שעון החומרה של PTP‏ (PHC) בקובץ התצורה.

הגדרה רגילה

כדי להגדיר את chrony בגרסה 4.6.1 ובגרסאות קודמות במופע U4P או U4C, צריך לבצע את הפעולות הבאות:

מאתרים את מספר האינדקס של מכשיר ה-PHC שמשויך ל-vNIC. בדוגמה הבאה נעשה שימוש ב-vNIC הראשון.
```
ethtool -T NIC0
```
מחליפים את NIC0 בשם המתאים שקיבלתם קודם, למשל enp22s0f0. אם צריך, תוכלו להיעזר במאמר קבלת שמות של ממשקי רשת.
1. בדיקת הפלט של PTP Hardware Clock:NUMBER
  
  בפלט לדוגמה מוצג הערך PTP Hardware Clock: 1, שתואם ל-/dev/ptp1.
```
Time stamping parameters for enp22s0f0:
Capabilities:
      hardware-receive
      software-receive
      software-system-clock
      hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
      off
Hardware Receive Filter Modes:
      none
      all
```

הפלט ethtool בשלב הקודם הראה ש-enp22s0f0 משתמש ב-/dev/ptp1. בדוגמה הבאה, השעון של המערכת מסונכרן עם השעון הפיזי של כרטיס ה-NIC המתאים ל-enp22s0f0 על ידי ציון: refclock PHC /dev/ptp1:nocrossts poll -1.

# Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC /dev/ptp0:nocrossts poll -1 noselect
refclock PHC /dev/ptp1:nocrossts poll -1
refclock PHC /dev/ptp2:nocrossts poll -1 noselect

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC /dev/ptp0 poll -1 noselect
refclock PHC /dev/ptp1 poll -1 noselect
refclock PHC /dev/ptp2 poll -1 noselect

כדי להחיל את ההגדרה, מפעילים מחדש את chrony באמצעות הפקודה הבאה:
```
systemctl restart chronyd
```

‫chrony מתעד את הנתונים הסטטיסטיים של סנכרון השעון ב-/var/log/chrony/tracking.log, באמצעות שעון החומרה של PTP שנבחר כמקור הזמן.

הגדרת DPDK

כדי להגדיר את chrony בגרסה 4.6.1 ובגרסאות קודמות במכונת U4C שמשתמשת ב-DPDK, צריך לבצע את הפעולות הבאות:

מאתרים את מספר האינדקס של מכשיר ה-PHC שמשויך ל-vNIC של nic0.
```
ethtool -T NIC0
```
מחליפים את NIC0 בשם המתאים שקיבלתם קודם, למשל enp22s0f0. אם צריך, אפשר לעיין במאמר בנושא קבלת שמות של ממשקי רשת.
1. בודקים את הפלט של PTP Hardware Clock:NUMBER
  
  בדוגמה הזו של הפלט מוצג הערך PTP Hardware Clock: 0, שמתאים לערך /dev/ptp0.
```
Time stamping parameters for enp22s0f0:
Capabilities:
      hardware-receive
      software-receive
      software-system-clock
      hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
      off
Hardware Receive Filter Modes:
      none
      all
```

הפלט ethtool בשלב הקודם הראה ש-enp22s0f0 משתמש ב-/dev/ptp0. בדוגמה הבאה, שעון המערכת מסונכרן עם השעון של כרטיס הרשת הפיזי התואם של enp22s0f0, על ידי ציון refclock PHC /dev/ptp0:nocrossts poll -1.

# Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure the nic0 interface clock for tracking and select it as the source.
# If nic0 uses a PHC index other than 0 (such as /dev/ptp1), replace /dev/ptp0.
refclock PHC /dev/ptp0:nocrossts poll -1

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC /dev/ptp0 poll -1 noselect

כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:
```
systemctl restart chronyd
```

‫chrony מתעד נתונים סטטיסטיים של סנכרון השעון ביומנים /var/log/chrony/tracking.log באמצעות שעון החומרה של PTP שנבחר כמקור הזמן.

הגדרת `chrony` בגרסה 4.7 ואילך במכונות U4S

מומלץ להשתמש בגרסאות chrony 4.7 ואילך עבור מופעי U4S. אם משתמשים בגרסאות קודמות, יכולות להופיע שגיאות לעיתים קרובות כי מכשיר הסנכרון של השעון ב-Compute Engine למכונות וירטואליות (ptp_kvm) יכול לגרום לשינויים במספרי האינדקס של מכשירי PHC.

ההגדרה לדוגמה של מכונות U4S דומה לזו של מכונות U4P ו-U4C, אבל יש כמה הבדלים:

בדוגמה הזו יש כרטיס רשת וירטואלי אחד. למכונה ב-U4S יכולים להיות כמה vNIC, אבל כולם מגובים על ידי אותו NIC פיזי וניגשים לאותו שעון של NIC פיזי.
מדידת זמן מדויקת (PTM) לא זמינה.

כדי להגדיר את chrony בגרסאות 4.7 ואילך במכונה של U4S:

# Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC NIC0:nocrossts poll -1

מחליפים את NIC0 בשם המתאים שקיבלתם קודם, למשל enp22s0f0. אם צריך, אפשר לעיין במאמר בנושא קבלת שמות של ממשקי רשת.

כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:
```
systemctl restart chronyd
```
‫chrony מתעד ביומנים נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של NIC0 כמקור הזמן.

אימות ההגדרות של `chrony`

כדי לוודא ש-chrony מוגדר בצורה נכונה, מריצים את הפקודה הבאה:

chronyc sourcestats

אם ההגדרה בוצעה בהצלחה, הפלט ייראה כך:

Name/IP Address             NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PHC0                        5   3     2     -0.002      0.014     +9ns     2ns
PHC1                        5   3     2     -0.003      0.007     -0ns     1ns
PHC2                        5   3     2     -0.004      0.016    +33ns     2ns
PHC3                        5   5     2     +0.002      0.078   +135ns    10ns
PHC4                        5   3     2     -0.005      0.077   +130ns     9ns
PHC5                        5   5     2     -0.006      0.131   +123ns    16ns

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

שינוי ההגדרה של `chrony`

אם רוצים לשנות את ה-NIC הפיזי שאליו מסנכרנים את שעון המערכת של המכונה, אפשר לעדכן את ההגדרות באופן הבא:

מסירים את noselect מהשורה שכוללת את שם ה-vNIC שרוצים להשתמש בשעון ה-NIC הפיזי התואם שלו.
מוסיפים את noselect לשורה שכוללת את שם ה-vNIC שרוצים להפסיק להשתמש בשעון ה-NIC הפיזי התואם שלו.
מפעילים מחדש את chronyd כדי להחיל את ההגדרות החדשות: systemctl restart chronyd.

מעקב אחרי סנכרון הזמן

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

המדדים הזמינים לסנכרון זמן

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

מדידה המדד הזמין והתיאור שלו

שעון המערכת של המכונה לשעון של כרטיס הרשת הפיזי

מדידה	המדד הזמין והתיאור שלו
שעון המערכת של המכונה לשעון של כרטיס הרשת הפיזי	`logging.googleapis.com/user/phc-clock-max-error` המדד הזה בודק את הדיוק של הסנכרון בין שעון המערכת של המופע לבין השעון של כרטיס ה-NIC הפיזי בשרת המארח שלו. כדי להגדיר את המדד הזה, צריך לאסוף אותו מ-Ops Agent וליצור מדד מבוסס-יומן כמו שמתואר במאמר הגדרת מדד מותאם אישית לשעון המערכת של המופע, שיוצר גם לוח בקרה מותאם אישית. בנוסף, אתם יכולים להשתמש במדד הזה בתהליכים שמתוארים בקטע שימוש במדדי Cloud Monitoring.
שעון של כרטיס רשת פיזי ל-UTC	`compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty` המדד הזה מייצג את גבול השגיאה המקסימלי של שעון כרטיס ה-NIC הפיזי בהשוואה לשעון UTC בפועל. הוא מדווח באופן אוטומטי ל-Cloud Monitoring. אפשר להציג את המדד הזה, להגדיר מדיניות התראות וליצור לוחות בקרה מותאמים אישית כמו שמתואר במאמר שימוש במדדים של Cloud Monitoring. המדד הזה נכלל גם בלוח הבקרה שנוצר על ידי הסקריפט בקטע הגדרת מדד בהתאמה אישית לשעון המערכת של המכונה.
סטטוס התקינות הכללי של השעון הפיזי של ה-NIC	`compute.googleapis.com/instance/time/firefly_nic_sync_healthy` המדד הבוליאני הזה מציין את סטטוס התקינות הכללי של השעון הפיזי של כרטיס הרשת, כולל סנכרון בין כרטיסי רשת וסנכרון בין כרטיס רשת ל-UTC. הוא מדווח אוטומטית ל-Cloud Monitoring. אתם יכולים לצפות במדד הזה, להגדיר מדיניות התראות וליצור מרכזי בקרה בהתאמה אישית, כמו שמתואר במאמר שימוש במדדים של Cloud Monitoring.

logging.googleapis.com/user/phc-clock-max-error

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

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

שעון של כרטיס רשת פיזי ל-UTC

compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty

המדד הזה מייצג את גבול השגיאה המקסימלי של שעון כרטיס ה-NIC הפיזי בהשוואה לשעון UTC בפועל. הוא מדווח באופן אוטומטי ל-Cloud Monitoring.

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

סטטוס התקינות הכללי של השעון הפיזי של ה-NIC

compute.googleapis.com/instance/time/firefly_nic_sync_healthy

המדד הבוליאני הזה מציין את סטטוס התקינות הכללי של השעון הפיזי של כרטיס הרשת, כולל סנכרון בין כרטיסי רשת וסנכרון בין כרטיס רשת ל-UTC. הוא מדווח אוטומטית ל-Cloud Monitoring.

אתם יכולים לצפות במדד הזה, להגדיר מדיניות התראות וליצור מרכזי בקרה בהתאמה אישית, כמו שמתואר במאמר שימוש במדדים של Cloud Monitoring.

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

הגדרת מדד מותאם אישית לשעון המערכת של המכונה

בקטע הזה מופיעה דוגמה להגדרת מעקב שמבצעת את הפעולות הבאות:

הגדרת סוכן התפעול לאיסוף היומן של chrony מהמכונה, כדי לדייק בסנכרון
מגדירה את Cloud Monitoring כך שיקלוט את היומן המתאים מכל המכונות בפרויקט כמדד מבוסס-יומנים.

הגדרת Google Cloud Ops Agent במכונה

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

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

מוסיפים את ההגדרות הבאות לקובץ /etc/google-cloud-ops-agent/config.yaml:

logging:
  receivers:
    chrony_tracking_receiver:
      type: files
      include_paths:
        - /var/log/chrony/tracking.log
  processors:
    chrony_tracking_processor:
      type: parse_regex
      regex: "^.*PHC.*  (?<max_error>[-\d\.eE]+)$"
  service:
    pipelines:
      chrony_tracking_pipeline:
        receivers: [chrony_tracking_receiver]
        processors: [chrony_tracking_processor]

מפעילים מחדש את סוכן תפעול באמצעות הפקודה הבאה:
```
systemctl restart google-cloud-ops-agent
```

הגדרת מדד מבוסס-יומנים ולוח בקרה בפרויקט

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

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

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

#!/bin/bash

if [ -z "$1" ]; then
    echo "Usage: setup_logging.sh <project_id>" >&2
    exit 1
fi

PROJECT_ID="$1"
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID  --format="value(projectNumber)")
SERVICE_ACCOUNT_EMAIL=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

# Grant permissions:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/compute.instanceAdmin"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/monitoring.metricWriter"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/logging.logWriter"

# Configure log-based metric
METRIC_CONF='
{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "logName=~\".*/logs/chrony_tracking_receiver\"",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": [ { "key": "instance_id", "valueType": "STRING",
          "description": "Instance ID for the source instance" } ]
  },
  "valueExtractor": "REGEXP_EXTRACT(jsonPayload.max_error, \"(.*)\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 1.0E-6, 5.0E-6, 1.0E-5, 1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  },
  "labelExtractors": {
    "instance_id": "REGEXP_EXTRACT(resource.labels.instance_id, \"(.*)\")"
  }
}
'
echo "$METRIC_CONF" > /tmp/clock-error-metric.json
gcloud logging metrics create --project=${PROJECT_ID} phc-clock-max-error --config-from-file=/tmp/clock-error-metric.json

# Create a dashboard plotting the clock accuracy

DASHBOARD_CONF='
{
  "displayName": "Clock Accuracy",
  "dashboardFilters": [],
  "description": "",
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "height": 19,
        "width": 48,
        "widget": {
          "title": "Combined Accuracy With Threshold",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "prometheusQuery": "(\n  histogram_quantile(\n    1, \n    sum by (le, instance_id) (\n      increase({\"__name__\"=\"logging.googleapis.com/user/phc-clock-max-error_bucket\", monitored_resource=\"gce_instance\"}[${__interval}])\n    )\n  ) * 1e9\n) \n+ on(instance_id) \nmax by (instance_id) (\n  max_over_time({\"__name__\"=\"compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty\", monitored_resource=\"gce_instance\"}[${__interval}])\n)",
                  "unitOverride": "ns"
                }
              }
            ],
            "thresholds": [
              {
                "color": "COLOR_UNSPECIFIED",
                "direction": "DIRECTION_UNSPECIFIED",
                "label": "",
                "targetAxis": "Y1",
                "value": 30000
              }
            ],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      },
      {
        "yPos": 19,
        "height": 16,
        "width": 24,
        "widget": {
          "title": "NIC-UTC sync accuracy",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "minAlignmentPeriod": "60s",
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "timeSeriesFilter": {
                    "aggregation": {
                      "alignmentPeriod": "60s",
                      "crossSeriesReducer": "REDUCE_SUM",
                      "groupByFields": [
                        "metric.label.\"instance_name\"",
                        "metric.label.\"nic_id\"",
                        "resource.label.\"instance_id\""
                      ],
                      "perSeriesAligner": "ALIGN_MEAN"
                    },
                    "filter": "metric.type=\"compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty\" resource.type=\"gce_instance\""
                  },
                  "unitOverride": ""
                }
              }
            ],
            "thresholds": [],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      },
      {
        "yPos": 19,
        "xPos": 24,
        "height": 16,
        "width": 24,
        "widget": {
          "title": "VM-NIC sync Accuracy",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "minAlignmentPeriod": "60s",
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "timeSeriesFilter": {
                    "aggregation": {
                      "alignmentPeriod": "60s",
                      "crossSeriesReducer": "REDUCE_PERCENTILE_99",
                      "groupByFields": [
                        "metric.label.\"instance_id\""
                      ],
                      "perSeriesAligner": "ALIGN_DELTA"
                    },
                    "filter": "metric.type=\"logging.googleapis.com/user/phc-clock-max-error\""
                  },
                  "unitOverride": ""
                }
              }
            ],
            "thresholds": [],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}
'

echo "$DASHBOARD_CONF" > /tmp/metrics-dashboard.json

gcloud monitoring dashboards create --project=${PROJECT_ID} --config-from-file=/tmp/metrics-dashboard.json

שימוש במדדים של Cloud Monitoring

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

בנוסף למסוף Google Cloud , אפשר ליצור מרכזי בקרה בהתאמה אישית, להגדיר התראות ולשאול שאילתות על המדדים באמצעות Monitoring API.

הצגת מדדים במעקב

בקטע הזה מוסבר איך לראות את המדדים ב-Monitoring.

המסוף

כדי לראות את המדדים של משאב במעקב באמצעות Metrics Explorer:

במסוף Google Cloud , נכנסים לדף Metrics explorer:
כניסה לדף Metrics Explorer

אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.
בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של App Hub, בוחרים את הפרויקט המארח של App Hub או את פרויקט הניהול של התיקייה לניהול אפליקציות.
ברכיב Metric, מרחיבים את התפריט Select a metric, מזינים VM instance בסרגל הסינון ומשתמשים בתפריטי המשנה כדי לבחור את סוג המשאב הספציפי ואת המדד:
1. בתפריט Active resources בוחרים באפשרות VM instance.
2. כדי לבחור מדד, משתמשים בתפריטים Active metric categories ו-Active metrics. במאמר מדדים זמינים לסנכרון זמן מפורטת רשימה של המדדים הזמינים.
3. לוחצים על אישור.
כדי להוסיף מסננים שמסירים סדרות של נתונים מתוצאות השאילתה, משתמשים ברכיב Filter.
מגדירים את אופן התצוגה של הנתונים. כברירת מחדל, בתצוגה נצברים המדדים מכל המכונות ומכרטיסי ה-NIC הפיזיים. כדי להציג מדדים לכל מכונה ולכל כרטיס רשת, ברכיב Aggregation בוחרים באפשרות Unaggregated.
מידע נוסף על הגדרת תרשים זמין במאמר איך בוחרים מדדים כשמשתמשים ב-Metrics Explorer.

הגדרה של כללי מדיניות התראות

בקטע הזה מוסבר איך להגדיר מדיניות התראות.

כשמגדירים איך כלי המעקב מעריך תנאי כשנתונים מפסיקים להגיע, מומלץ לבחור באפשרות Missing data points treated as values that violate the policy condition (נקודות נתונים חסרות נחשבות כערכים שמפירים את תנאי המדיניות). האפשרות הזו עוזרת לזהות אובדן נתונים שקט. עם זאת, ההגדרה הזו גורמת להתראות חיוביות כוזבות כשמכונה נמחקת.

המסוף

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

נכנסים לדף Alerting במסוף Google Cloud :
נכנסים לדף Alerting.

אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.
אם עדיין לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף התראות.
בדף Alerting, לוחצים על Create policy.
כדי לבחור את המדד, מרחיבים את התפריט Select a metric ומבצעים את הפעולות הבאות:
1. כדי להגביל את התפריט לרשומות רלוונטיות, מזינים VM Instance בסרגל הסינון. אם לא מופיעות תוצאות אחרי סינון התפריט, משביתים את המתג Show only active resources & metrics.
2. בשדה Resource type, בוחרים באפשרות VM Instance.
3. בקטע Metric category, בוחרים באפשרות Instance.
4. בשדה Metric, בוחרים מדד מהרשימה Available metrics for time synchronization.
5. לוחצים על אישור.
לוחצים על הבא.
ההגדרות בדף Configure alert trigger קובעות מתי ההתראה תופעל. בוחרים סוג תנאי, ואם צריך, מציינים סף. למידע נוסף, קראו את המאמר יצירת מדיניות התראות לפי סף של מדד.
לוחצים על הבא.
אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על Notification channels. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על OK.
אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של ההתראה. השדה הזה קובע מתי מערכת Monitoring תסגור התראות אם אין נתוני מדדים.
אופציונלי: לוחצים על Documentation ומוסיפים את המידע שרוצים לכלול בהודעה.
לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
לוחצים על יצירת מדיניות.

מידע נוסף מופיע בסקירה הכללית על התראות.

יצירת לוחות בקרה מותאמים אישית של Monitoring

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

המסוף

במסוף Google Cloud , עוברים לדף Dashboards:
עוברים אל מרכזי בקרה.

אם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
לוחצים על יצירת לוח בקרה.
אופציונלי: מעדכנים את שם מרכז הבקרה בשם שמתאר את מרכז הבקרה.
לכל ווידג'ט שרוצים להוסיף למרכז הבקרה, לוחצים על Add widget, ממלאים את תיבת הדו-שיח ולוחצים על Apply.

מידע נוסף על הוספת ווידג'טים זמין בדפים הבאים:

דוגמה: יצירת לוח בקרה מותאם אישית שמשלב מדדי דיוק

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

בקטע הזה יש דוגמה לשאילתת PromQL שאפשר להדביק בלוח בקרה בהתאמה אישית ב-Monitoring. מידע נוסף על PromQL מופיע במאמר PromQL ל-Cloud Monitoring.

השאילתה בקטע הזה יוצרת מדד דיוק כולל על ידי שילוב של:

המדד שמודד את הדיוק של השעון של מערכת המופע ביחס לשעון של כרטיס ה-NIC הפיזי (phc-clock-max-error)
המדד שבודק את הדיוק של השעון הפיזי של ה-NIC ביחס ל-UTC (firefly_utc_traceable_uncertainty)

המסוף

פועלים לפי השלבים כדי להיכנס לכלי לעריכת קוד עבור PromQL.

מזינים את השאילתה הבאה בשדה הטקסט:

(
  histogram_quantile(
   1,
   sum by (le, instance_id) (
     increase({"__name__"="logging.googleapis.com/user/phc-clock-max-error_bucket", monitored_resource="gce_instance"}[${__interval}])
   )
  ) * 1e9
)
+ on(instance_id)
max by (instance_id) (
 max_over_time({"__name__"="compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty", monitored_resource="gce_instance"}[${__interval}])
)

לוחצים על Run Query.

למידע נוסף על השימוש בכלי לעריכת קוד ושמירת התרשימים, קראו את המאמר שימוש בכלי לעריכת קוד ב-PromQL.

פתרון בעיות

יכול להיות שתקבלו פלט לא צפוי כשתאמתו את ההגדרה של chrony, כמו הפלט הבא שמציין שchrony לא הופעל:

506 Cannot talk to daemon

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

journalctl -u chronyd.service

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

Feb 19 06:19:42 host-name systemd[1]: Starting chronyd.service - NTP client/server...
Feb 19 06:19:42 host-name chronyd[35160]: chronyd version 4.6.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
Feb 19 06:19:42 host-name chronyd[35160]: Setting filter length for PHC0 to 1
Feb 19 06:19:42 host-name chronyd[35160]: Could not open eth0 : No such file or directory
Feb 19 06:19:42 host-name chronyd[35160]: Fatal error : Could not open PHC
Feb 19 06:19:42 host-name chronyd[35157]: Could not open PHC
Feb 19 06:19:42 host-name systemd[1]: chronyd.service: Control process exited, code=exited, status=1/FAILURE
Feb 19 06:19:42 host-name systemd[1]: chronyd.service: Failed with result 'exit-code'.
Feb 19 06:19:42 host-name systemd[1]: Failed to start chronyd.service - NTP client/server.

בעיות מוכרות

הבעיות הבאות עלולות להתרחש כשמגדירים זמן מדויק במכונות U4:

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

הגדרת זמן מדויק למכונות U4 Compute Engine

איך זה עובד

לפני שמתחילים

יצירת מכונת U4

מוודאים שלא פועלים שירותים אחרים לסנכרון השעון

איך מקבלים את השמות של ממשקי הרשת

הגדרה של chrony כך שייטען רק אחרי שמנהלי ההתקנים של הרשת יציבים

הגדרה רגילה

הגדרת DPDK

הגדרת chrony לשימוש בשעון של כרטיס ה-NIC הפיזי שסונכרן עם Firefly

הגדרת chrony מגרסה 4.7 ואילך במכונות U4P ו-U4C

הגדרה רגילה

הגדרת DPDK

הגדרת chrony בגרסה 4.6.1 ומטה במכונות U4P ו-U4C

הגדרה רגילה

הגדרת DPDK

הגדרת chrony בגרסה 4.7 ואילך במכונות U4S

אימות ההגדרות של chrony

שינוי ההגדרה של chrony

מעקב אחרי סנכרון הזמן

המדדים הזמינים לסנכרון זמן

הגדרת מדד מותאם אישית לשעון המערכת של המכונה

הגדרת Google Cloud Ops Agent במכונה

הגדרת מדד מבוסס-יומנים ולוח בקרה בפרויקט

שימוש במדדים של Cloud Monitoring

הצגת מדדים במעקב

המסוף

הגדרה של כללי מדיניות התראות

המסוף

יצירת לוחות בקרה מותאמים אישית של Monitoring

המסוף

דוגמה: יצירת לוח בקרה מותאם אישית שמשלב מדדי דיוק

המסוף

פתרון בעיות

בעיות מוכרות

הגדרה של `chrony` כך שייטען רק אחרי שמנהלי ההתקנים של הרשת יציבים

הגדרת `chrony` לשימוש בשעון של כרטיס ה-NIC הפיזי שסונכרן עם Firefly

הגדרת `chrony` מגרסה 4.7 ואילך במכונות U4P ו-U4C

הגדרת `chrony` בגרסה 4.6.1 ומטה במכונות U4P ו-U4C

הגדרת `chrony` בגרסה 4.7 ואילך במכונות U4S

אימות ההגדרות של `chrony`

שינוי ההגדרה של `chrony`