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

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

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

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

כדי לוודא שהנתונים מגובים, תמיד צרו קובץ snapshot של הדיסק לפני שאתם מבצעים פעולות לפתרון בעיות.
אם דיסק האתחול של Linux מלא ב-100%, יכול להיות שהפקודה growpart תיכשל כי היא לא יכולה ליצור קבצים זמניים בספרייה /tmp. כדי לפתור את הבעיה, צריך לאלץ את הפקודה להשתמש בזיכרון לקבצים זמניים במקום זאת, על ידי הגדרת משתנה הסביבה TMPDIR: sudo env TMPDIR=/dev/shm growpart /dev/DEVICE_NAME PARTITION_NUMBER. לדוגמה: sudo env TMPDIR=/dev/shm growpart /dev/sda 1.
אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא התהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים האלה:
1. התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
```
gcloud init
```
  הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
2. הגדרת אזור ותחום כברירת מחדל.

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

בהמשך מפורטות שגיאות נפוצות שעשויות להתרחש כשמנסים לשנות את Extreme Persistent Disk או את Google Cloud Hyperdisk. יכול להיות שהשגיאות האלה יופיעו בכמה מקומות, כמו בפלט של הקונסולה הטורית או ביומני האפליקציה.

Disk cannot be resized due to being rate limited.

Cannot update provisioned iops due to being rate limited.

Cannot update provisioned throughput due to being rate limited.

אלה מגבלות הזמן לשינוי דיסקים:

אפשר לשנות את הגודל של Extreme Persistent Disk או של נפח Hyperdisk Throughput רק פעם אחת בפרק זמן של 6 שעות.
אפשר לשנות את הגודל של נפח Hyperdisk Extreme רק פעם אחת בפרק זמן של 4 שעות.
אפשר לשנות את קצב ה-IOPS או את קצב העברת הנתונים שהוקצו לנפח Hyperdisk רק פעם אחת בפרק זמן של 4 שעות.

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

שגיאות שקשורות לנפח האחסון בכונן

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

דיסקים מלאים

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

No space left on device

Not enough storage is available to process this command

Error: There isn't enough space on the disk.

כדי לפתור את הבעיה:

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

אין גישה למכונה הווירטואלית כי דיסק האתחול מלא

אם דיסק האתחול של המכונה הווירטואלית מלא, יכול להיות שלא תצליחו לגשת אליה. התרחיש הזה יכול להיות קשה לזיהוי, כי לא תמיד ברור מתי בעיות הקישוריות קשורות לדיסק אתחול מלא. בהמשך מפורטות דוגמאות לשגיאות נפוצות שעשויות להתרחש אם אתם לא מצליחים לגשת ל-VM מ-Google Cloud CLI או באמצעות RDP כי דיסק האתחול מלא:

  Network error: Software caused connection abort

  Your Remote Desktop Services session has ended. The connection was lost because the remote computer is running low on memory or disk space.

  ERROR: (gcloud.compute.ssh) Could not SSH into the instance.  It is possible
  that your SSH key has not propagated to the instance yet. Try running this
  command again.  If you still cannot connect, verify that the firewall and
  instance are set to accept ssh traffic.

  You cannot connect to the VM instance because of an unexpected error. Wait a
  few moments and then try again.

  No space left on device

  ERROR Exception calling the response handler. [Errno 2] No usable temporary
  directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...

כדי לפתור את הבעיות האלה:

מוודאים שהסיבה לכשל בקישוריות של ה-VM היא דיסק אתחול מלא:
- במכונות וירטואליות של Linux, בודקים את הפלט של היציאה הטורית:
```
gcloud compute instances tail-serial-port-output VM_NAME
```
  אם דיסק האתחול מלא, הפלט מכיל את ההודעה No space left on device.
- במכונות וירטואליות של Windows, משתמשים ב-Special Administration Console (SAC)‎:
  
  אחרי שפותחים ערוץ של שורת הפקודה ב-SAC, מריצים את הפקודה הבאה כדי לבדוק את השטח הפנוי:
```
wmic logicaldisk get caption,freespace,size
```
אם עדיין לא עשיתם זאת, צרו קובץ snapshot של דיסק האתחול של ה-VM.
נסו להפעיל מחדש את ה-VM.
אם עדיין אין לכם גישה למכונה הווירטואלית, בצעו את הפעולות הבאות:
1. עוצרים את ה-VM:
```
gcloud compute instances stop VM_NAME
```
  מחליפים את VM_NAME בשם של המכונה הווירטואלית.
2. מגדילים את דיסק האתחול:
```
gcloud compute disks resize BOOT_DISK_NAME --size DISK_SIZE
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫BOOT_DISK_NAME: השם של דיסק האתחול של המכונה הווירטואלית
  - ‫DISK_SIZE: הגודל החדש של דיסק האתחול, בג'יגה-בייט
  לדוגמה, כדי לשנות את הגודל של דיסק בשם example-disk-1 ל-6GB, מריצים את הפקודה הבאה:
```
gcloud compute disks resize example-disk-1 --size=6GB
```
3. מפעילים את ה-VM:
```
gcloud compute instances start VM_NAME
```
מנסים שוב להתחבר ל-VM באמצעות SSH. אם עדיין אין לכם גישה למכונה הווירטואלית, אתם יכולים לבצע אחת מהפעולות הבאות:
- יוצרים דיסק חדש מקובץ ה-snapshot. מידע נוסף זמין במאמר שחזור של מכונה וירטואלית שאין אליה גישה או שדיסק האתחול שלה מלא.
- במכונות וירטואליות של Linux בלבד, מפעילים את המכונה הווירטואלית באופן זמני במצב חילוץ באמצעות הכלי בקוד פתוח GCE Rescue. אחר כך מבצעים את השלבים שמפורטים בקטע בעיות במערכת הקבצים.

בעיות במערכת הקבצים

בקטעים הבאים מתוארות בעיות נפוצות במערכת הקבצים ואיך לפתור אותן.

שינוי הגודל של מערכת הקבצים

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

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

כדי לבדוק אם גודל דיסק האתחול של ה-VM השתנה, אפשר להשתמש באחת מהשיטות הבאות:
- בדיקת הפלט של היציאה הטורית. מחפשים שורה שמציינת שהגודל של מחיצת הבסיס השתנה.
  
  לדוגמה, במכונות וירטואליות עם קובצי אימג' של Debian, אם שינוי הגודל האוטומטי הצליח, יומני המסוף כוללים את השורה ... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.
- אם אתם יכולים להתחבר ל-VM של Linux באמצעות SSH, הריצו את הפקודה df -h כדי לבדוק אם יש מקום בכונן.
  
  לדוגמה, בפלט הזה אפשר לראות שמערכת הקבצים הבסיסית מלאה ב-92%:
```
Filesystem                                    Size  Used Avail Use% Mounted on
udev                                           63G     0   63G   0% /dev
tmpfs                                          13G  1.4M   13G   1% /run
/dev/sda1                                     339G  315G   24G  92% /
```
אם גודל מערכת הקבצים הבסיסית לא השתנה ב-VM, שנו את הגודל של מערכת הקבצים והמחיצות באופן ידני.

מגבלת Storage Spaces Direct (S2D)‎

כשמשתמשים ב-Storage Spaces Direct‏ (S2D), אי אפשר להגדיל את הקיבולת על ידי שינוי הגודל של דיסקי האחסון המתמידים הבסיסיים. אם משנים את גודל הדיסקים ברמת החומרה, S2D לא יזהה את המקום שנוסף, ויכול להיות שלא תהיה גישה לנתונים. כדי להגדיל את הקיבולת, הוסיפו שרתים או כוננים במקום לשנות את הגודל של דיסקי האחסון המתמידים הקיימים.

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

נכנסים לדף VM instances במסוף Google Cloud .

כניסה לדף VM instances
לצד המכונה עם הדיסק ששיניתם את הגודל שלו, לוחצים על הלחצן RDP. הדפדפן פותח חיבור RDP למכונה.
לוחצים לחיצה ימנית על הכפתור Windows Start ובוחרים באפשרות Disk Management כדי לפתוח את הכלי Disk Management. לדוגמה, בצילום המסך הבא אפשר לראות שבדיסק 1 יש מחיצת הגנה של Storage Spaces:

פרטי S2D מניהול הדיסק.

לחלופין, אפשר להריץ אחת מהפקודות הבאות של PowerShell כדי למצוא את כל הדיסקים מסוג Persistent Disk שמשויכים להגדרת S2D.

   Get-Disk | Where-Object Model -eq "Storage Space"

   Get-PhysicalDisk | Where-Object {$_.ObjectId -like "*Spaces*"}