טיפים כלליים לשימוש ב-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 VPC מופעל מעקב של 10 דקות אחרי חיבורים לפרוטוקולי IP שיש להם מושג של חיבור (לדוגמה, TCP). המשמעות היא שמותרים חבילות נתונים נכנסות שמשויכות לחיבור קיים, כל עוד נשלחה או התקבלה לפחות חבילת נתונים אחת לחיבור ב-10 הדקות האחרונות. אם לא נשלחו או התקבלו חבילות לחיבור במשך 10 דקות או יותר, רשומות המעקב של החיבור הלא פעיל יוסרו. אחרי שרשומות המעקב של החיבור הוסרו, Google Cloud לא מאפשרת חבילות נכנסות נוספות עד שנשלחת לפחות חבילה יוצאת חדשה אחת. מעקב החיבורים הזה חל על כל המקורות והיעדים – גם על כתובות IP פנימיות וגם על כתובות IP חיצוניות .

כדי למנוע חיבורים לא פעילים, צריך לבצע את הפעולות הבאות:

  • מגדירים את הפרמטרים של TCP keep-alive במערכת ההפעלה לפרק זמן של פחות מ-10 דקות. המגבלה הזו מבטיחה שלפחות חבילה אחת תישלח במסגרת הזמן.

  • חשוב לוודא שאפליקציות שפותחות חיבורי TCP עושות זאת עם האפשרות SO_KEEPALIVE מופעלת.

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

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.

מידע נוסף זמין במאמר בנושא 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.