פתרון בעיות בגישה לשרת המטא-נתונים

במאמר הזה מוסבר איך לפתור בעיות בשרת המטא-נתונים של Compute Engine.

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

  • השם של הדומיין של שרת המטא-נתונים לא נפתר
  • החיבור לשרת המטא-נתונים נחסם בגלל אחת מהסיבות הבאות:
    • הגדרת חומת אש ברמת מערכת ההפעלה
    • הגדרת שרת proxy
    • ניתוב בהתאמה אישית

אם למכונות וירטואליות אין גישה לשרת המטא-נתונים, יכול להיות שחלק מהתהליכים ייכשלו.

למידע על פתרון בעיות ב-gke-metadata-server, אפשר לעיין במאמר פתרון בעיות באימות GKE.

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

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, מאתחלים את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

פתרון בעיות בקודי שרת

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

קודי שרת נפוצים

קודי השרת האלה מוחזרים לעיתים קרובות משרת המטא-נתונים.

קוד בצד השרת תיאור רזולוציה
200 OK: הבקשה בוצעה בהצלחה לא רלוונטי
400 בקשה שגויה: סטטוס השגיאה הזה מוחזר בתרחישים שונים, למשל כשבקשה כוללת פרמטרים של שאילתה לא תקינים או כשלא מתקיימות הדרישות של נקודת הקצה הזו. בודקים את הודעת השגיאה כדי לקבל הצעות לפתרון השגיאה.
403 Forbidden: סטטוס השגיאה הזה מוחזר בתרחישים הבאים:
  • נקודת הקצה המבוקשת מושבתת בהגדרות של הפרויקט או של המופעים
  • הבקשה נכשלת בבדיקות האבטחה. הבעיה הזו יכולה לקרות אם חיבור ה-TCP לשרת נסגר בשכבת הרשת.
 צריך לבדוק את הגדרות הפרויקט והמופע כדי לוודא שנקודת הקצה מופעלת, או לבדוק את הגדרות הרשת.
404 לא נמצא: נקודת הקצה המבוקשת לא קיימת תיקון נתיב הבקשה
429 יותר מדי בקשות: הבעיה הזו מתרחשת כי חלק מנקודות הקצה משתמשות בהגבלת קצב כדי למנוע עומס יתר בשירות התומך. מומלץ מאוד לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). מידע נוסף זמין ברשימת נקודות הקצה (endpoint) עם הגבלת קצב. ממתינים כמה שניות ומנסים להתקשר שוב.
503 השירות לא זמין: שרת המטא-נתונים לא מוכן להצגה. שרת המטא-נתונים עשוי להחזיר את קוד המצב Error 503 בכל אחד מהמקרים הבאים:
  • השרת של המטא-נתונים עדיין נמצא בתהליך אתחול
  • השרת למטא-נתונים נמצא בתהליך העברה
  • השרת של המטא-נתונים לא זמין באופן זמני
  • המחשב המארח מבצע אירוע תחזוקה
  • יכול להיות ששרת המטא-נתונים יחזיר 503 כשמגבילים את קצב הנתונים של חלק מנקודות הקצה.
 שגיאות 503 הן זמניות והן אמורות להיפתר תוך כמה שניות לכל היותר. כדי לפתור את הבעיה, ממתינים כמה שניות ומנסים להתקשר שוב.

קודי שרת נדירים

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

קוד בצד השרת תיאור רזולוציה
301 הועבר לצמיתות: הערך הזה מופיע בנתיבים שיש בהם הפניות אוטומטיות עדכון נתיב הבקשה
405 Not Allowed: קוד השגיאה הזה מוחזר אם מתבקשת שיטה שלא נתמכת.

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

קודי שגיאה של נקודות קצה שהוגבלה להן מהירות השליחה

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

נקודת קצה (endpoint) קוד סטטוס תיאור
oslogin/ 429 מגבלות הקצב של OS Login משותפות בין בקשות של משתמשים, הרשאות וקבוצות.
instance/service-accounts/identity 429 נקודת הקצה לחתימת זהויות מחזירה קוד תגובה מסוג 429 כדי לציין תגובה שמוגבלת על ידי קצב.
instance/service-accounts/default/token 429 אין הגבלת קצב על טוקנים ששמורים במטמון בשרת המטא-נתונים. אסימונים שלא נשמרו במטמון כפופים להגבלת קצב יצירת הבקשות.
instance/guest-attributes/ 429, 503 יכול להיות שנחיל הגבלת קצב על בקשות למאפייני אורחים אם תחרגו מ-3 בקשות לשנייה או מ-10 בקשות לדקה. אם מתרחש ויסות, מוחזרים קודי השגיאה 429 או 503.

ניסיון חוזר להדרכה

שרת המטא-נתונים מחזיר באופן שגרתי את קודי השגיאה 503 ו-429. כדי שהאפליקציות שלכם יהיו עמידות, מומלץ להטמיע לוגיקה של ניסיון חוזר באפליקציות שמבצעות שאילתות בשרת המטא-נתונים. מומלץ גם להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) בסקריפטים כדי להתמודד עם מצבים שבהם יש הגבלת קצב.

פתרון בעיות בבקשות שנכשלו לשרת המטא-נתונים

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

curl: (6) Could not resolve host: metadata.google.internal

postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused

אם ה-VM איבד את הגישה לשרת המטא-נתונים, צריך לבצע את הפעולות הבאות:

Linux

  1. מתחברים ל-VM של Linux.

  2. במכונת ה-Linux הווירטואלית, מריצים את הפקודות הבאות כדי לבדוק את הקישוריות לשרת המטא-נתונים:

    1. שליחת שאילתה לשרת השמות של הדומיין:

      nslookup metadata.google.internal

      הפלט של מכונות וירטואליות שמשתמשות ב-IPv4 אמור להיראות כך:

      Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254

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

      ping -c 3 metadata.google.internal

      הפלט אמור להיראות כך:

      PING metadata.google.internal (169.254.169.254) 56(84) bytes of data.
64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms

      ping -c 3 169.254.169.254

      הפלט אמור להיראות כך:

      PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.
64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms

    3. אם משתמשים במופע עם IPv6 בלבד, צריך לוודא שאפשר להגיע לשרת המטא-נתונים של IPv6. כדי לבדוק, מריצים את הפקודה הבאה:

      ping -c 3 fd20:ce::254

      הפלט אמור להיראות כך:

      PING fd20:ce::254(fd20:ce::254) 56 data bytes
64 bytes from fd20:ce::254: icmp_seq=1 ttl=255 time=1.11 ms

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

      1. בודקים ששרת השמות מוגדר לשרת המטא-נתונים:

        cat /etc/resolv.conf

        הפלט אמור להיראות כך:

        domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

        אם הפלט לא כולל את השורות הקודמות, אפשר לעיין במסמכי התיעוד של מערכת ההפעלה כדי לקבל מידע על עריכת מדיניות DHCP כדי לשמור את הגדרת שרת השמות ב-169.254.169.254. אם הגדרות של DNS אזורי חלות על מכונות וירטואליות בפרויקט, שינויים ב-/etc/resolv.conf מוחלפים תוך שעה. אם הפרויקט שלכם עדיין משתמש ב-DNS גלובלי, קובץ resolv.conf יחזור ל-DHCP שמוגדר כברירת מחדל תוך 24 שעות.

      2. בודקים שקיימת מיפוי בין שם הדומיין של שרת המטא-נתונים לבין כתובת ה-IP שלו:

        cat /etc/hosts

        השורה הבאה צריכה להופיע בפלט:

        169.254.169.254 metadata.google.internal  # Added by Google

        אם הפלט לא כולל את השורה הקודמת, מריצים את הפקודה הבאה:

        echo "169.254.169.254 metadata.google.internal" >> /etc/hosts

Windows

  1. מתחברים ל-VM של Windows.

  2. מריצים את הפקודות הבאות מ-VM של Windows:

    1. שליחת שאילתה לשרת השמות של הדומיין:

      nslookup metadata.google.internal

      הפלט אמור להיראות כך:

      Server:  UnKnown
Address:  10.128.0.1

Non-authoritative answer:
Name:    metadata.google.internal
Address:  169.254.169.254

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

      ping -n 3 metadata.google.internal

      הפלט אמור להיראות כך: 

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255


      ping -n 3 169.254.169.254

      הפלט אמור להיראות כך:

      Pinging 169.254.169.254 with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

    3. אם למכונה הווירטואלית יש כתובת IPv6, צריך לבדוק שאפשר להגיע למכונה שהיא רק IPv6. כדי לבדוק, מריצים את הפקודה הבאה:

      ping -n 3 fd20:ce::254

      הפלט של מכונות וירטואליות עם IPv6 אמור להיראות כך:

      Pinging fd20:ce::254 with 32 bytes of data:
Reply from fd20:ce::254: bytes=32 time=1ms TTL=255

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

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

        route print

        הפלט צריך לכלול את הפרטים הבאים:

        Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1

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

        $Adapters = Get-NetKVMAdapterRegistry
$FirstAdapter = $Adapters | Select-Object -First 1
route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1

      2. בודקים שהמיפוי בין שם הדומיין של שרת המטא-נתונים לבין כתובת ה-IP שלו קיים:

        type %WINDIR%\System32\Drivers\Etc\Hosts

        השורה הבאה צריכה להופיע בפלט:

        169.254.169.254 metadata.google.internal  # Added by Google

        אם הפלט לא כולל את השורה הקודמת, מריצים את הפקודה הבאה:

        echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts

פתרון בעיות שקשורות לבקשות שנכשלו במהלך שימוש בשרת proxy ברשת

שרת proxy ברשת מונע גישה ישירה של מכונות וירטואליות לאינטרנט. כל השאילתות שנשלחות מתוך מכונה וירטואלית מטופלות על ידי שרת ה-proxy.

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

אם לא מגדירים את NO_PROXY, יכול להיות שיופיעו שגיאות כשמריצים פקודות של Google Cloud CLI או כששולחים שאילתות ישירות לשרת המטא-נתונים, כי הקריאות ל-metadata.google.internal יישלחו לשרת ה-proxy בלי שהן ייפתרו באופן מקומי במופע עצמו.

דוגמה לשגיאה שיכולה להופיע:

ERROR 403 (Forbidden): Your client does not have permission to get URL

כדי לפתור את בעיית ה-proxy הזו, צריך להוסיף את שם המארח ואת כתובת ה-IP של שרת המטא-נתונים למשתנה הסביבה NO_PROXY. לשם כך:

Linux

  1. מתחברים ל-VM של Linux.

  2. מריצים את הפקודות הבאות מהמכונה הווירטואלית של Linux:

    export no_proxy=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal

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

    echo no_proxy=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal >> /etc/environment

Windows

  1. מתחברים ל-VM של Windows.

  2. מריצים את הפקודות הבאות מ-VM של Windows:

    set NO_PROXY=169.254.169.254,fd20:ce::254,metadata,metadata.google.internal

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

    setx NO_PROXY 169.254.169.254,fd20:ce::254,metadata,metadata.google.internal /m

פתרון בעיות בבקשות שנכשלו לנקודת הקצה של שרת המטא-נתונים של HTTPS

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

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

אישור לקוח שגוי

השגיאות הבאות מתרחשות אם מספקים ערך שגוי לסימן -E flag.

  • curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate
required, errno 0
  • curl: (58)  unable to set private key file:
  • curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory

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

שם מארח שגוי

השגיאה הבאה מתרחשת אם שם המארח שמשמש לגישה לשרת המטא-נתונים לא נמצא באישור.

curl: (60) SSL: no alternative certificate subject name matches target host name

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

אישור בסיס או אישור לקוח שגויים

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

curl: (77) error setting certificate verify locations:

המצב הזה יכול לקרות בתרחישים הבאים:

  • יכול להיות שהנתיב של הדגל --cacert לא תקין
  • יכול להיות שאישור הבסיס חסר במאגר האישורים המהימנים

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

לדוגמה, כדי לשלוף בשאילתה את קובץ האימג' לאתחול של מכונה וירטואלית, מריצים את השאילתה הבאה:

user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \
    -E /run/google-mds-mtls/client.key \
    --cacert /run/google-mds-mtls/root.crt \
    -H "Metadata-Flavor: Google"

פתרון בעיות שקשורות לפורמט שגוי של כותרות

שרת המטא-נתונים מבצע בדיקות פורמט כדי לוודא שהכותרות עומדות בהנחיות לפורמט הכותרות RFC 7230 סעיף 3.2. אם פורמט הכותרת לא עובר את הבדיקות האלה, קורה אחד מהדברים הבאים:

  • הבקשה אושרה. עם זאת, תקבלו המלצות לגבי מכונות וירטואליות ששולחות בקשות לשרת המטא-נתונים עם כותרות בפורמט שגוי. ההמלצות נשלחות פעם אחת לכל מכונה וירטואלית. אפשר לגשת להמלצות האלה באמצעות Google Cloud CLI או Recommender API בארכיטקטורת REST.

    אחרי שמיישמים את ההמלצה, מגדירים את סטטוס ההמלצה לערך succeeded.

  • החל מ-20 בינואר 2024, שרת המטא-נתונים דוחה כל בקשה עם כותרת בפורמט שגוי.

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

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

Metadata-Flavor : Google

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

Metadata-Flavor: Google

תקין: אין רווח בכותרת

Metadata-Flavor:Google

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

פתרון בעיות שקשורות לטוקן

יכול להיות שתופיע אחת מהשגיאות הבאות כשמבצעים שאילתה בשרת המטא-נתונים:

  • ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
  • curl: (22) The requested URL returned error: 401

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