בעיות מוכרות ומגבלות

בדף הזה מפורטות המגבלות הידועות של Google Cloud NetApp Volumes.

בעיות כלליות

בקטע הזה מתוארות בעיות נפוצות ב-NetApp Volumes.

בעיות בתמיכה בכתובות IP של לקוחות שהן לא RFC 1918 (PUPI) ברמת השירות המאוחדת של Flex

בעיה: רמת השירות Flex Unified לא תומכת בכתובות IP של לקוחות שאינן RFC 1918 (PUPI).

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

פתרון: כדי לפתור את הבעיה, אפשר לנסות את האפשרויות הבאות:

  • הקצאת כתובות IP מסוג RFC 1918: מגדירים את הלקוחות כך שישתמשו בכתובות IP פרטיות מסוג RFC 1918.

  • שימוש ברמת שירות אחרת: שימוש ברמת שירות שתומכת בכתובות IP של לקוחות PUPI, כמו Standard,‏ Premium,‏ Extreme או Flex File.

  • שליחת בקשה להגדרת חומת אש באופן ידני: כפתרון זמני, אפשר לפנות אל Google Cloud Customer Care כדי להגדיר באופן ידני כללי חומת אש לדחיית תעבורת נתונים נכנסת (ingress) עבור טווח הלקוחות של PUPI. הערה יכול להיות שהגדרה ידנית תדרוש מאמצי תמיכה שוטפים. כדי להמשיך באפשרות הזו, צריך לשלוח בקשת תמיכה עם הפרטים הבאים:

    • טווח כתובות ה-IP של ה-PUPI של הלקוח (לדוגמה, 100.64.0.0/10)

    • יציאות פרוטוקול נדרשות (NFS,‏ SMB או iSCSI)

    • שם אזור היעד ומאגר האחסון

שגיאות Not found בהרצת פעולות גיבוי אחרי יצירת נפח אחסון

הבעיה: אם מריצים פעולות גיבוי כמו CreateBackup, RestoreVolume או UpdateBackupConfig מיד אחרי שיוצרים נפח במצב ONTAP, הפעולות עלולות להיכשל עם שגיאה Not found.

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

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

נפחי אחסון של קבצים ב-Flex לא מגיבים לפינג

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

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

במהלך ההגדרה של החיבור netapp.servicenetworking.goog, אם טווח ה-CIDR חופף לטווח ה-CIDR שמשמש לחיבור אחר של גישה לשירותים פרטיים באותו VPC, עלולה להתרחש אובדן קישוריות לסירוגין של חיבור להרכבת אמצעי אחסון. כדי להימנע מהבעיה הזו, צריך להשתמש בטווחים לא חופפים.

יכול להיות שיהיו שיבושים בגישת הלקוח לנפחים שהועברו מ-Cloud Volumes Service ל-NetApp Volumes כשמעדכנים את ההגדרות של נפח NFS

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

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

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

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

כרכים שהושפעו

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

  • נפחי אחסון שנמצאים בשכפול פעיל של נפחי אחסון משוכפלים. המשכת השכפול אחרי שהוא נעצר עלולה לגרום לבעיה.

  • כל אמצעי האחסון שמופעל בהם NFS ויש להם מדיניות ייצוא.

  • כרכים שבהם מדיניות הייצוא שונה בין המקור ליעד.

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

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

    • אם מדיניות הייצוא זהה, לא צריך לעשות שום דבר.

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

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

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

הודעת שגיאה כשמשתמשים במשאבי Cloud Volumes Service‏ (CVS) ובמשאבי NetApp Volumes ביחד

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

  • הפרויקט שימש בעבר ל-CVS.

  • בוצעה פעולה של רשימת משאבים ב-CVS בפרויקט שלא כולל משאבי NetApp Volumes.

אלה הודעות השגיאה הנפוצות:

  • Host project and service project must be using the same service.

  • Resources from CVS and NetApp Volumes may not be used together in a single region.

  • Cannot share VPC between 3P and 1P networks.

כדי לפתור את הבעיה, צריך לפנות אל Cloud Customer Care ולבקש לאפס את הפרויקטים או האזורים הספציפיים כדי להשתמש רק במשאבי NetApp Volumes.

יצירת הקובץ נכשלת עם שגיאות No space left on device או File too large בספרייה ספציפית

הבעיה: כשמנסים לכתוב, להעתיק או ליצור קבצים חדשים או תיקיות משנה בכרך מחובר, הפעולה נכשלת עם השגיאה No space left on device (errno 28 / ENOSPC) או File too large (errno 27 / EFBIG).

זה קורה גם כששאילתות של שטח דיסק בצד הלקוח (כמו df -h) ומסוףGoogle Cloud מראים שיש נפח אחסון לוגי זמין. השגיאה מתרחשת בספרייה ספציפית. יצירת הקובץ מצליחה בספריות אחרות באותו אמצעי אחסון.

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

אימות:

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

  1. בדיקת יצירת קובץ עם לוקליזציה: מנסים ליצור קובץ בספרייה חדשה לגמרי, שנוצרה לאחרונה, באותו נפח אחסון בדיוק: bash mkdir /mount_point/test_dir && touch /mount_point/test_dir/test_file.txt אם הפעולה הזו מצליחה אבל הכתיבה לספרייה המקורית נכשלת, סביר להניח שהגעתם למגבלת הספרייה.
  2. הערכת מספר הרשומות בספרייה: ספירת מספר הרשומות בספרייה הבעייתית: bash find /mount_point/offending_directory -maxdepth 1 | wc -l
  3. בדיקת הגודל של קובץ האינדקס של הספרייה: בודקים את טביעת הרגל של המטא-נתונים של הספרייה: bash ls -ld /mount_point/offending_directory גודל קובץ גדול במיוחד של ספרייה מצביע על ניפוח מטא-נתונים מסיבי של הספרייה.

פתרון:

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

  • הטמעת חלוקת ספרייה: שינוי המבנה של האפליקציה או עומס העבודה כדי לחלק את הקבצים לספריות משנה היררכיות מקוננות (למשל /aa/bb/filename.txt) במקום לשמור מספרים גדולים של קבצים בספרייה שטוחה אחת.
  • בנייה מחדש של ספריות גדולות מדי: מחיקת קבצים מספרייה שעברה את המגבלה מסירה את השמות שלהם, אבל לא מצמצמת באופן אוטומטי את הגודל הפיזי של קובץ אינדקס הספרייה במערכת הקבצים הבסיסית. כדי לפנות את כל המקום בספרייה, מעתיקים או מעבירים את הקבצים הפעילים לספרייה חדשה, ואז מוחקים את הספרייה הישנה והגדולה.

בעיות בשילוב עם Active Directory

בקטעים הבאים מפורטות בעיות מוכרות בשילוב עם Active Directory.

בעיות קישוריות

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

שינוי הגדרת האתר של Active Directory במדיניות Active Directory לא משפיע על מאגרי האחסון ברמת השירות של Flex File. ההגדרה הזו פועלת במאגרי Flex Unified.

אי אפשר לצרף את NetApp Volumes לבקרי דומיין שמבוססים על Windows 2025

בגלל רגרסיה ב-Windows 2025, NetApp Volumes לא יכולים להצטרף לדומיין באמצעות בקר דומיין של Windows 2025.

נכון ל-9 בספטמבר 2025, מיקרוסופט פרסמה את KB5065431 ואת KB5065426 כדי לפתור את הבעיה הזו. ‫Windows 2025 לא תומך בהצפנת RC4, ולכן צריך להפעיל הצפנת AES לאימות Active Directory.

מידע נוסף זמין במאמר התקשורת בין בקר הדומיין לבין Windows 2025 או גרסאות קודמות עלולה להיכשל בגלל אכיפה של SMB 3.1.1.

התקשורת של בקר הדומיין עם Windows 2025 או גרסאות קודמות עלולה להיכשל בגלל אכיפה של SMB 3.1.1

בקרי דומיין של Windows 2025 אוכפים את SMB 3.1.1 לתקשורת עם לקוחות Active Directory. בנוסף, במדיניות 18.6.7.6 של Center for Internet Security (CIS) מומלץ להשתמש ב-SMB 3.1.1 בגרסאות קודמות של Windows.

למרות ש-NetApp Volumes תומכים ב-SMB 3.1.1 לתקשורת בין לקוחות SMB לבין שרת SMB של NetApp Volumes, הם תומכים רק ב-SMB 2.1 וב-SMB 3.0 כשמתחברים ל-Active Directory כלקוח.

אם בקרי הדומיין מאפשרים רק חיבורים ל-SMB 3.1.1,‏ NetApp Volumes לא יכול להתחבר ל-Active Directory, מה שגורם לשיבושים בשירות.

כדי לשמור על תאימות, מומלץ להגדיר את SMB 2.1 כגרסת ה-SMB המינימלית הנתמכת בבקרי הדומיין. צריך להחיל את ההגדרה הזו על כל בקרי הדומיין, או על כל בקר דומיין באתר Active Directory אם משתמשים במדיניות Active Directory שמבוססת על אתרים.

בדוגמה הבאה אפשר לראות איך מגדירים את גרסת ה-SMB המינימלית הנתמכת ל-2.1:

 Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB210

מידע נוסף על שינוי הגדרות SMB באמצעות PowerShell או מדיניות קבוצתית זמין במאמר ניהול ניבי SMB ב-Windows וב-Windows Server 2025.

בעיות ב-CMEK

בקטעים הבאים מפורטות בעיות ידועות בפעולות של מפתחות הצפנה בניהול הלקוח (CMEK).

שגיאה (ListKmsConfigs)Invalid value for enum type

במהלך העברה של נפח אחסון מהצפנה שמנוהלת על ידי המערכת להצפנה שמנוהלת על ידי הלקוח, הפקודה ListKmsConfigs מחזירה מדי פעם שגיאה מסוג Invalid value for enum type. אחרי שההעברה מסתיימת, הפקודה ListKmsConfigs חוזרת לפעול כרגיל.

יצירת המדיניות KmsConfig נכשלה

לפעמים, יצירת מדיניות KmsConfig נכשלת ומונעת ממך ליצור מדיניות נוספת. במקרה כזה, צריך לפנות אל Google Cloud Customer Care.

בעיות ומגבלות בשכפול נפחים

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

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

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

Google Cloud במסוף מוצגים מאגרי אחסון ללא מדיניות Active Directory משויכת

כשיוצרים שכפול של נפח אחסון מקור במסוף Google Cloud , רשימת מאגרי האחסון שאפשר לבחור מתוכם כדי ליצור את נפח האחסון של היעד כוללת מאגרי אחסון שאין להם מדיניות של Active Directory. בחירה של מאגר אחסון ללא מדיניות Active Directory מובילה לכשל בשכפול.

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

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

בריכות לא תואמות שמוצגות

כשמשנים את מאגר האחסון (רמת השירות), יכול להיות שבמסוף Google Cloud יוצגו מאגרים לא תואמים. אם מנסים לעבור למאגר אחסון לא תואם, הניסיון נכשל ומוצגת הודעת שגיאה.

העברה של CMEK לא נחסמת

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

בעיות ב-FlexCache

בקטע הזה מתוארות בעיות מוכרות בתכונה FlexCache.

יכול להיות ששינויים בנפח האחסון של FlexCache במסוף Google Cloud ייכשלו

אפשר לשנות נפחי FlexCache רק באמצעות ה-API או Google Cloud CLI. אחרי שיוצרים נפחי FlexCache, הם מוצגים במסוף Google Cloud , אבל אפשר רק לצפות בהם או למחוק אותם. ניסיונות לעדכן אותם באמצעותGoogle Cloud המסוף עלולים להיכשל. במקרים כאלה, צריך להשתמש ב-Google Cloud CLI כדי לבצע שינויים.

יצירת נפח אחסון ל-FlexCache נכשלת כשהערך של snapshot-directory מוגדר כ-true

כרכים של FlexCache לא תומכים באפשרות snapshot-directory. ב-API, ערך ברירת המחדל של הפרמטר הזה הוא false, אבל ב-Google Cloud CLI ערך ברירת המחדל הוא true. לכן, כשיוצרים נפח FlexCache באמצעות Google Cloud CLI, צריך לכלול באופן מפורש את --snapshot-directory false כדי למנוע כשל ביצירה.