טיפים כלליים לשימוש ב-Compute Engine

בדף הזה מפורטים טיפים שיכולים לעזור לכם אם נתקלתם בבעיות בשימוש ב-Compute Engine.

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

הצגת פורמטים שונים של תשובות

רוב הפעולות ב-Google Cloud CLI מתבצעות באמצעות קריאות ל-REST API. התוצאות שמוצגות בפורמט יפה כוללות רק את המידע הכי חשוב שמוחזר על ידי פקודה ספציפית. כדי לראות את פורמטי התשובות השונים, משתמשים בדגל --format שמציג את התשובה בפורמטים שונים של פלט, כולל json, yaml ו-text. לדוגמה, כדי לראות רשימה של מופעים ב-JSON, משתמשים בפקודה --format json:

gcloud compute instances list --format json

צפייה ביומנים של gcloud compute

ה-CLI של gcloud יוצר ומאחסן יומנים בקובץ יומן שאפשר לשלוח לו שאילתות. הקובץ נמצא במיקום $HOME/.config/gcloud/logs. כדי לראות את קובץ היומן האחרון במערכת הפעלה מבוססת Linux, מריצים את הפקודה:

$ less $(find ~/.config/gcloud/logs | sort | tail -n 1)

קובץ היומן כולל מידע על כל הבקשות והתשובות שנוצרו באמצעות הכלי gcloud CLI.

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

 gcloud config set core/max_log_days DAYS_TO_RETAIN_LOGS

השבתת רישום ביומן של קבצים ב-CLI של gcloud:

הקובץ $HOME/.config/gcloud/logs תופס מקום במערכת הקבצים המקומית. כמות היומנים שנוצרת עלולה להיות גדולה מדי ביחס לנפח האחסון במערכת הקבצים המקומית, ולגרום לבעיות כמו:

  • ניצול המרחב מגיע ל-100% במופע.
  • הפקודות של ה-CLI של gcloud לרישום ביומן לא מופעלות כי אין מקום ליצור קובץ חדש במערכת הקבצים המקומית.

כדי לשנות את ההתנהגות של ה-CLI של gcloud ולהשבית את רישום היומנים בקובץ, משתמשים במאפיין disable_file_logging:

 gcloud config set core/disable_file_logging True

בחירת שמות של משאבים

כשבוחרים שמות למשאבים, חשוב לזכור שהשמות הידידותיים האלה עשויים להיות גלויים בלוחות בקרה של תמיכה ותפעול ב-Compute Engine. לכן מומלץ להשתמש בשמות משאבים שלא חושפים מידע רגיש.

תקשורת עם האינטרנט

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

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

חיבורים לא פעילים

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

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

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

  • מגדירים את הפרמטרים הבאים של TCP keepalive:

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

    • מרווח הזמן בין בדיקות ה-keepalive של TCP.

    • keepalive probes, שמייצג את המספר הכולל של בדיקות פעילות של TCP שלא אושרו ונשלחות ברצף לפני שהחיבור נחשב לחיבור שנפל.

אפליקציות לקוח או שרת יכולות להגדיר את פרמטרים של TCP keepalive באמצעות אפשרויות שקע כמו TCP_KEEPIDLE, TCP_KEEPINTVL ו-TCP_KEEPCNT, או שאתם יכולים להגדיר את הפרמטרים של TCP keepalive למערכת ההפעלה שלכם.

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

Linux


מריצים את הפקודה הבאה:

$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5

כדי לוודא שההגדרות יישמרו אחרי הפעלה מחדש, מוסיפים אותן לקובץ /etc/sysctl.conf. פרמטרים של ליבת המערכת חלים גם על IPv4 וגם על IPv6, למרות שהם כוללים ipv4 בשם שלהם.

מידע נוסף זמין במאמר Linux TCP Keepalive HOWTO.

macOS


מריצים את הפקודה הבאה:

$ sudo sysctl -w net.inet.tcp.always_keepalive=1 net.inet.tcp.keepidle=60000 net.inet.tcp.keepinit=60000 net.inet.tcp.keepintvl=60000

Windows


בנתיב הרישום HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, מוסיפים את ההגדרות הבאות באמצעות סוג הנתונים DWORD, או עורכים את הערכים אם ההגדרות כבר קיימות:

KeepAliveInterval: 1000
KeepAliveTime: 60000
TcpMaxDataRetransmissions: 10

גישה ל-Compute Engine בתור משתמש SSH אחר

כברירת מחדל, כלי שורת הפקודה gcloud compute משתמש במשתנה $USER כדי להוסיף משתמשים לקובץ /etc/passwd לצורך התחברות למופעים באמצעות SSH. אפשר לציין משתמש אחר באמצעות הדגל --ssh-key-file PRIVATE_KEY_FILE כשמריצים את הפקודה gcloud compute ssh. לדוגמה:

gcloud compute ssh example-instance --ssh-key-file my-private-key-file

מידע נוסף מופיע במאמרי העזרה של gcloud.

אינטראקציה עם המסוף הטורי

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

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

איך נמנעים מפיצול מנות (packet fragmentation) במופעים שנבנו מתמונות בהתאמה אישית

לרשת ה-VPC יש יחידת העברה מקסימלית (MTU) של 1460 בייט כברירת מחדל לתמונות של Linux ולתמונות של Windows Server. עם זאת, אפשר לשנות את ה-MTU של הרשת. פרטים נוספים זמינים במאמר סקירה כללית על יחידת העברה מקסימלית במסמכי ה-VPC.

כשיוצרים אפליקציות לקוח שמתקשרות עם מכונות של Compute Engine דרך שקעי UDP, אפשר להימנע מפיצול אם מגדירים את הגודל המקסימלי של נתוני חבילת ה-UDP ל-28 בייט פחות מה-MTU של הרשת. לדוגמה, אם ה-MTU של הרשת הוא 1,460 בייט, אפשר לשלוח עד 1,432 בייט של נתוני UDP לכל מנה בלי פיצול. אם ה-MTU של הרשת הוא 1,500 בייט, אפשר לשלוח עד 1,472 בייט של נתוני UDP ללא פיצול. ה-28 בייט משמשים לכותרת של חבילת IPv4 (20 בייט) ולכותרת של חבילת נתונים UDP (8 בייט). אפשר להגדיר את ה-MTU של הרשת למקסימום של 8,896 בייט.

אבחון הביצועים והמעבד

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

כדי לזהות את הבעיה, בודקים את הפלט של היציאה הטורית ומחפשים את רשומת היומן הבאה: x86/split lock detection: #DB: <process_name>/<pid> took a bus_lock trap at address: 0x<address>.

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

מידע נוסף מופיע במאמר בנושא פתרון בעיות בנעילות של אוטובוס CPU.