בדף הזה מפורטים טיפים שיכולים לעזור לכם אם נתקלתם בבעיות בשימוש ב-Compute Engine.
לקבלת עזרה בפתרון בעיות ספציפיות, אפשר לעיין באחד מהסעיפים הבאים:
- שלבים לפתרון בעיות כלליות במכונות, למשל אם המכונה לא מופעלת, מפורטים במאמר פתרון בעיות כללי.
- שלבים לפתרון בעיות במופעי Windows מפורטים במאמר פתרון בעיות במופעי Windows.
הצגת פורמטים שונים של תשובות
רוב הפעולות ב-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, המערכת משביתה את garbage collection ביומן ולא מוחקת את קובצי היומן.
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. לכן מומלץ להשתמש בשמות משאבים שלא חושפים מידע רגיש.
תקשורת עם האינטרנט
למופע יש גישה ישירה לאינטרנט רק אם מתקיימים שני התנאים הבאים:
- למופע יש כתובת IP חיצונית.
- רשת ה-VPC של המכונה משתמשת במסלול ברירת מחדל שהניתוב הבא שלו הוא שער ברירת המחדל לאינטרנט.
מכונות יכולות גם לגשת לאינטרנט באופן עקיף, על ידי התחברות דרך Cloud NAT או שרת proxy שמבוסס על מכונה. לשיקולים נוספים, כולל הגדרת כללי חומת אש, אפשר לעיין במאמר דרישות לגישה לאינטרנט.
חיבורים במצב לא פעיל
ברשתות VPC מופעל מעקב של 10 דקות אחרי חיבורים לפרוטוקולי IP שיש להם מושג של חיבור (לדוגמה, TCP).Google Cloud המשמעות היא שמותר להעביר מנות נתונים נכנסות שמשויכות לחיבור קיים, כל עוד נשלחה או התקבלה לפחות מנה אחת עבור החיבור ב-10 הדקות האחרונות. אם לא נשלחו או התקבלו חבילות לחיבור במשך 10 דקות או יותר, רשומות המעקב של החיבור הלא פעיל יוסרו. אחרי שהערכים של מעקב החיבור יוסרו, Google Cloud לא יתאפשרו חבילות נכנסות נוספות עד שתישלח לפחות חבילה יוצאת חדשה אחת. מעקב החיבור הזה חל על כל המקורות והיעדים – גם על כתובות IP פנימיות וגם על כתובות IP חיצוניות .
כדי למנוע חיבורים בלי פעילות, צריך לבצע את הפעולות הבאות:
מגדירים את הפרמטרים של TCP keep-alive במערכת ההפעלה לפרק זמן של פחות מ-10 דקות. כך מוודאים שלפחות חבילה אחת נשלחת במסגרת הזמן.
חשוב לוודא שאפליקציות שפותחות חיבורי TCP עושות זאת עם האפשרות
SO_KEEPALIVEמופעלת.
בדוגמאות הבאות אפשר לראות איך מגדירים פרמטרים של הודעת keep-alive ב-TCP במערכת ההפעלה עם ערך של דקה אחת למרווח הזמן. כדי להבין איך להגדיר את האפליקציה או את ספריית התוכנה כך שישתמשו ב-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 של הרשת. פרטים נוספים זמינים במאמר סקירה כללית על יחידת העברה מקסימלית (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 בייט.