פתרון בעיות

בדף הזה מתוארות שיטות לפתרון בעיות נפוצות שלפעמים נתקלים בהן במהלך השימוש ב-Cloud Storage.

בGoogle Cloud לוח הבקרה של Service Health בהתאמה אישית אפשר למצוא מידע על אירועים שמשפיעים על Google Cloud שירותים כמו Cloud Storage.

רישום בקשות גולמיות ביומן

בעבודה עם כלים כמו gcloud או ספריות הלקוח של Cloud Storage, הכלי מטפל ברוב המידע על הבקשות והתשובות. אבל לפעמים צריך לדעת פרטים שיכולים לעזור לפתור בעיות, או כשרוצים לפרסם שאלות בפורומים כמו Stack Overflow. אפשר להיעזר בהוראות הבאות כדי לקבל את הכותרות של הבקשות והתשובות בכלי שלכם:

המסוף

ההצגה של פרטי הבקשות והתשובות משתנה בהתאם לדפדפן שדרכו אתם נכנסים למסוף Google Cloud . בדפדפן Google Chrome:

  1. לוחצים על לחצן התפריט הראשי של Chrome‏ ().

  2. בוחרים באפשרות More Tools.

  3. לוחצים על Developer Tools.

  4. בחלונית שמופיעה, לוחצים על הכרטיסייה Network.

שורת הפקודה

משתמשים בדגלים גלובליים לניפוי באגים בבקשה. לדוגמה:

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

ספריות לקוח

C++‎

  • מגדירים את משתנה הסביבה CLOUD_STORAGE_ENABLE_TRACING=http כדי לקבל את כל תעבורת ה-HTTP.

  • מגדירים את משתנה הסביבה CLOUD_STORAGE_ENABLE_CLOG=yes כדי לקבל רישומי יומן של כל RPC.

C#‎

מוסיפים יומן באמצעות השיטה ApplicationContext.RegisterLogger ומגדירים אפשרויות רישום ביומן ב-handler של הודעת HttpClient. מידע נוסף זמין במאמרי העזרה לספריית הלקוח של C# ‎.

המשך

מגדירים את משתנה הסביבה GODEBUG=http2debug=1. מידע נוסף אפשר למצוא ב-Go package net/http.

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

Java

  1. יוצרים קובץ בשם logging.properties עם התוכן הבא:

    # Properties file which configures the operation of the JDK logging facility.
    # The system will look for this config file to be specified as a system property:
    # -Djava.util.logging.config.file=${project_loc:googleplus-simple-cmdline-sample}/logging.properties
    
    # Set up the console handler (uncomment "level" to show more fine-grained messages)
    handlers = java.util.logging.ConsoleHandler
    java.util.logging.ConsoleHandler.level = CONFIG
    
    # Set up logging of HTTP requests and responses (uncomment "level" to show)
    com.google.api.client.http.level = CONFIG
  2. משתמשים ב-log.properties עם Maven

    mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command

מידע נוסף אפשר למצוא במאמר שעוסק ב-Pluggable HTTP Transport.

Node.js

צריך להגדיר את משתנה הסביבה NODE_DEBUG=https לפני קריאה לסקריפט של הצומת.

PHP

מציינים handler ‏HTTP משלכם ללקוח באמצעות httpHandler, ומגדירים תווכה לרישום הבקשה והתשובה ביומן.

Python

משתמשים במודול הרישום ביומן. לדוגמה:

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

Ruby

בחלק העליון של .rb file אחרי require "google/cloud/storage", מוסיפים:

ruby
Google::Apis.logger.level = Logger::DEBUG

הוספת כותרות מותאמות אישית

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

שורת הפקודה

משתמשים בדגל --additional-headers, שזמין לרוב הפקודות. לדוגמה:

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

כש-HEADER_NAME ו-HEADER_VALUE מגדירים את הכותרת שמוסיפים לבקשה.

ספריות לקוח

C++‎

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

C#‎

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

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

המשך

אפשר להוסיף כותרות מותאמות אישית לכל קריאה ל-API שמתבצעת על ידי חבילת Storage באמצעות callctx.SetHeaders בהקשר שמועבר ל-method.

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

Java

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

Node.js

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

PHP

כל הפעלות ה-method שמפעילות בקשות http מקבלות גם ארגומנט $restOptions בתור הארגומנט האחרון. אפשר לתת כותרות מותאמות אישית לכל בקשה בנפרד או לכל לקוח בנפרד.

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

Python

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

Ruby

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

גישה לקטגוריות עם הגדרות CORS

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

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

  2. כשבודקים שליחה של בקשת CORS, צריך לוודא שלא שולחים בקשה לנקודת הקצה (endpoint) של storage.cloud.google.com, שלא מאפשרת בקשות CORS. למידע נוסף על נקודות הקצה שיש להן תמיכה ב-CORS, ראו תמיכה ב-CORS ב-Cloud Storage.

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

    1. לוחצים על תפריט Chrome ‏() בסרגל הכלים של הדפדפן.
    2. בוחרים באפשרות כלים נוספים > כלים למפתחים.
    3. לוחצים על הכרטיסייה Network.
    4. שולחים את הבקשה מהאפליקציה או משורת הפקודה.
    5. מאתרים את הבקשה בחלונית שמציגה את הפעילות ברשת.
    6. בעמודה Name, לוחצים על השם שתואם לבקשה.
    7. לוחצים על הכרטיסייה Headers כדי לראות את כותרות התגובות. לחלופין, לוחצים על הכרטיסייה Response כדי לראות את תוכן התגובה.

    אם אתם לא רואים בקשה ותגובה, יכול להיות שהדפדפן שלכם שמר במטמון ניסיון קודם שנכשל של בקשת קדם-הפעלה. ניקוי המטמון של הדפדפן אמור גם לנקות את המטמון של קדם-ההפעלה. אם לא, אפשר להגדיר את הערך של MaxAgeSec בהגדרות CORS שלכם לערך נמוך יותר מברירת המחדל של 3600 (60 דקות). אתם צריכים להמתין עד שיחלוף משך הזמן הקודם שנקבע ב-MaxAgeSec, ואז לנסות לשלוח את הבקשה שוב. הפעולה הזו מבצעת בקשת קדם-הפעלה חדשה, שמאחזרת את ההגדרות החדשות של CORS ומוחקת באופן סופי את רשומות המטמון. אחרי שסיימתם לנפות את הבאגים, אתם צריכים להגדיל את הערך של MaxAgeSec בחזרה לערך גבוה יותר כדי לצמצם את תעבורת נתוני קדם-ההפעלה לקטגוריה שלכם.

  4. לוודא שבבקשה יש כותרת Origin, ושערך הכותרת תואם לפחות לאחד מערכי Origins בהגדרות ה-CORS של הקטגוריה. שימו לב שחייבת להיות התאמה מדויקת בין הסכימה, המארח והיציאה של הערכים. הנה כמה דוגמאות של התאמות קבילות:

    • http://origin.example.com תואם ל-http://origin.example.com:80 (כי 80 היא יציאת ה-HTTP שמוגדרת כברירת מחדל), אבל לא תואם ל-https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 או ל-http://sub.origin.example.com.

    • https://example.com:443 תואם ל-https://example.com אבל לא ל-http://example.com או ל-http://example.com:443.

    • http://localhost:8080 תואם במדויק רק ל-http://localhost:8080 ולא ל-http://localhost:5555 או ל-http://localhost.example.com:8080.

  5. בבקשות פשוטות, מוודאים ש-method ה-HTTP של הבקשה תואמת לפחות לאחד מהערכים של Methods בהגדרות ה-CORS של הקטגוריה. בבקשות קדם-הפעלה, מוודאים שה-method שצוינה ב-Access-Control-Request-Method תואמת לפחות לאחד מהערכים של Methods.

  6. בבקשות קדם-הפעלה, בודקים אם הבקשה כוללת כותרת Access-Control-Request-Header אחת או יותר. במקרה כזה, אתם צריכים לוודא שכל ערך של Access-Control-Request-Header תואם לערך של ResponseHeader בהגדרות ה-CORS של הקטגוריה. כדי שבקשת קדם-ההפעלה תתבצע ללא שגיאות, כל הכותרות עם השמות ב-Access-Control-Request-Header חייבות להיות בהגדרות CORS, וצריכות לכלול כותרות CORS בתגובה.

קודי שגיאה

הרשימה הבאה כוללת קודי מצב נפוצים של HTTP שאולי תתקלו בהם.

‏‎400: Bad Request

הבעיה: כשביצעתם העלאה שניתן להמשיך, קיבלתם את השגיאה הזו ואת ההודעה Failed to parse Content-Range header.

הפתרון: הערך שבו השתמשתם בכותרת Content-Range לא תקין. לדוגמה, הערך Content-Range: */* לא תקין ובעצם הוא צריך להיות Content-Range: bytes */*. אם השגיאה הזו מופיעה, ההעלאה הנוכחית שניתן להמשיך כבר לא פעילה וצריך להתחיל העלאה חדשה שניתן להמשיך.

‫400: שגיאות ספציפיות ל-Storage Intelligence

פתרונות לשגיאות נפוצות שמתרחשות כשמגדירים או מנהלים את Storage Intelligence,‏ Storage Insights ופעולות אצווה ב-Storage מפורטים במאמר פתרון בעיות ב-Storage Intelligence.

‏‎401: Unauthorized

הבעיה: בקשות ישירות לקטגוריה ציבורית נכשלות, ומתקבלות התשובות HTTP 401: Unauthorized ו-Authentication Required.

הפתרון: מוודאים שהלקוח, או כל שרת proxy מתווך, לא מוסיפים את הכותרת Authorization לבקשות ל-Cloud Storage. כל בקשה עם הכותרת Authorization, גם אם היא ריקה, מאומתת כאילו הייתה ניסיון לאימות.

‏‎403: Account Disabled

הבעיה: ניסיתם ליצור קטגוריה, אבל קיבלתם את הודעת השגיאה 403 Account Disabled.

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

‏‎403: Forbidden

הבעיה: אמורה להיות לכם הרשאת גישה לקטגוריה או לאובייקט מסוים, אבל כשאתם מנסים להשתמש בה, מופיעה הודעת השגיאה 403 - Forbidden עם הודעה שדומה לזו: example@email.com doesn't have storage.objects.get access to the Google Cloud Storage object.

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

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

  2. האם ההרשאה שמצוינת בהודעת השגיאה היא ההרשאה שאתם צריכים? אם לא ציפיתם להרשאה הזו, כנראה שלכלי שבו אתם משתמשים נדרשת הרשאת גישה נוספת כדי להשלים את הטיפול בבקשה. לדוגמה, כדי למחוק בבת אחת כמות גדולה של אובייקטים בקטגוריה, gcloud צריך קודם ליצור רשימה של אובייקטים למחיקה בקטגוריה. לחלק הזה של פעולת המחיקה בכמות גדולה נדרשת הרשאת storage.objects.list, וזה מפתיע כי למחיקת אובייקט בדרך כלל נדרשת רק הרשאת storage.objects.delete. אם זו הסיבה להודעת השגיאה, בדקו אם קיבלתם את תפקידי ה-IAM עם ההרשאות הנדרשות הנוספות.

  3. האם קיבלתם את תפקיד ה-IAM במשאב המיועד או במשאב המקור? לדוגמה, אם קיבלתם תפקיד Storage Object Viewer בפרויקט ואתם מנסים להוריד אובייקט, ודאו שהאובייקט נמצא בקטגוריה שנמצאת בפרויקט. יכול להיות שבטעות יש לכם הרשאת Storage Object Viewer בפרויקט אחר.

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

    לדוגמה, נניח של-jane@example.com יש את התפקיד הבסיסי Owner (roles/owner) בפרויקט בשם my-example-project, ומדיניות IAM של הפרויקט מקצה את התפקיד Storage Object Creator (roles/storage.objectCreator) לערך הנוחות projectOwner:my-example-project. כתוצאה מכך, ל-jane@example.com יש את ההרשאות שמשויכות לתפקיד Storage Object Creator בקטגוריות בתוך my-example-project. אם ההרשאה הזו תוסר, jane@example.com תאבד את ההרשאות שמשויכות לתפקיד Storage Object Creator.

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

  5. האם יש מדיניות דחייה ב-IAM שמונעת ממך להשתמש בהרשאות מסוימות? אפשר לפנות לאדמין בארגון כדי לברר אם הוגדרה מדיניות IAM Deny.

‫403: ההרשאה נדחתה

בעיה: שגיאת דחיית הרשאה כשמגדירים או מנהלים את ההגדרה של Storage Intelligence למשאב.

פתרון: אם מופיעה שגיאת דחיית הרשאה עם הודעה שדומה ל-permission storage.intelligenceConfigs.update כשמנסים להגדיר ולנהל את Storage Intelligence עבור משאב, צריך לעיין בקטע בנושא הרשאות כדי להבין מה נדרש לפעולה שרוצים לבצע. כדי לפתור את הבעיה, צריך להעניק את ההרשאות המתאימות. אפשר לתת הרשאות בכל אחת מהדרכים הבאות:

  • צריך להעניק הרשאות IAM באותו משאב בהיררכיית המשאביםGoogle Cloud שבו מפעילים את Storage Intelligence.
  • מוודאים שמשאב ברמה גבוהה יותר ב Google Cloud היררכיית המשאבים מעביר את ההרשאות למשאב הצאצא.

‏‎409: Conflict

הבעיה: ניסיתם ליצור קטגוריה, אבל קיבלתם את השגיאה:

409 Conflict. Sorry, that name is not available. Please try a different one.

הפתרון: שם הקטגוריה שבו ניסיתם להשתמש (למשל, gs://cats או gs://dogs) כבר תפוס. ל-Cloud Storage יש מרחב שמות גלובלי, כך שאי אפשר לתת לקטגוריה שם של קטגוריה שכבר קיימת. בחרו שם שלא נמצא בשימוש.

‫412: הופרו אילוצים מותאמים אישית

הבעיה: הבקשות שלכם נדחות עם שגיאת 412 orgpolicy.

הבעיה: הבקשות שלכם נדחות עם שגיאת 412 Multiple constraints were violated.

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

‏‎429: Too Many Requests

הבעיה: הבקשות שלכם נדחות עם שגיאת 429 Too Many Requests.

הפתרון: אתם מגיעים למגבלה של מספר הבקשות שאפשר לבצע ב-Cloud Storage במשאב נתון. מידע נוסף על המגבלות ב-Cloud Storage אפשר למצוא במאמר בנושא המכסות של Cloud Storage.

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

  • אם עומס העבודה שלכם עלול להשתמש ב-50Gbps או יותר של תעבורת רשת יוצאת למיקומים ספציפיים, בדקו את השימוש ברוחב הפס כדי לוודא שלא חרגתם ממכסת רוחב הפס.

שגיאות בהקשר של אובייקט

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

‫400: חריגה ממגבלת ההקשר של האובייקט

הבעיה: השגיאה מציינת שהאובייקט חרג מהמגבלה של 50 הקשרים.

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

‫400: חריגה ממגבלת הגודל של מפתח או ערך של הקשר אובייקט

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

פתרון: כל מפתח וערך של הקשר אובייקט צריך להיות באורך של עד 256 בייט (בקידוד UTF-8). צריך לקצר את המפתח או את הערך ולנסות שוב.

‫400: חריגה ממגבלת הגודל המצטבר של ערך או מפתח הקשר של האובייקט

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

פתרון: הגודל הכולל של כל מפתחות ההקשר והערכים של אובייקט לא יכול לחרוג מ-25KiB‏ (25,600 בייטים). צריך לצמצם את כמות נתוני ההקשר הכוללת ולנסות שוב.

‫400: תווים אסורים במפתח או בערך של הקשר האובייקט

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

הפתרון: מפתחות וערכים של הקשר אובייקט לא יכולים להכיל גרש יחיד ('), מירכאות כפולות (") או לוכסן הפוך (\`), or forward slashes (/`). צריך לבדוק את ההקשרים ולהסיר את כל התווים הלא חוקיים.

‫400: המפתח או הערך של הקשר של האובייקט חייבים להתחיל בתו אלפאנומרי

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

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

‫400: מפתח או ערך של הקשר אובייקט ריקים

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

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

‫400: מפתח או ערך של הקשר אובייקט ב-UTF-8 לא תקינים

הבעיה: השגיאה מציינת שמפתח או ערך של הקשר של אובייקט הם לא מחרוזת UTF-8 תקינה.

פתרון: מוודאים שכל התווים במפתחות ובערכים של ההקשר מקודדים באמצעות UTF-8.

‫400: קידומת שמורה של מפתח הקשר של האובייקט

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

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

‫400: לא ניתן להוסיף לאובייקט יותר מ-50 קבוצות של הקשרים להוספה

הבעיה: השגיאה מציינת שלפרמטר drop_context_groups יכולים להיות עד 50 ערכים.

פתרון: צריך לצמצם את מספר הערכים בפרמטר drop_context_groups ולנסות שוב.

‫400: ערך לא תקין בשדה 'קבוצות של הקשרים של תפריטי הנפתחים'

הבעיה: השגיאה מציינת שהפרמטר drop_context_groups מכיל ערך לא תקין.

פתרון: הערך היחיד שאפשר להשתמש בו לפרמטר drop_context_groups הוא custom.

אבחון Google Cloud שגיאות במסוף

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

הפתרון: בהתראות במסוף Google Cloud אפשר לראות מידע מפורט על הפעולה שנכשלה:

  1. לוחצים על הלחצן Notifications () בכותרת של מסוף Google Cloud .

    הפעולות האחרונות שבוצעו במסוףGoogle Cloud יוצגו בתפריט נפתח.

  2. לוחצים על הפריט שרוצים לקבל עליו מידע נוסף.

    ייפתח דף שמציג מידע מפורט על הפעולה.

  3. אפשר ללחוץ על כל שורה כדי להרחיב ולראות מידע מפורט על השגיאה.

בעיה: כשאני משתמש במסוף Google Cloud , לא מוצגת לי עמודה מסוימת.

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

תיקיות מדומה ותיקיות מנוהלות

הבעיה: מחקתם כמה אובייקטים בקטגוריה, ועכשיו התיקייה שמכילה אותם לא מופיעה במסוף Google Cloud .

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

הבעיה: אין לי אפשרות ליצור תיקיות מנוהלות.

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

  • יש לכם תפקיד IAM שכולל את ההרשאה storage.managedfolders.create, כמו התפקיד 'אדמין של אובייקטים באחסון' (roles/storage.objectAdmin). במאמר איך משתמשים בהרשאות IAM מוסבר איך מקצים תפקידים.

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

  • אין תנאים של IAM בקטגוריה או בפרויקט שמשתמשים בסוג המשאב של הקטגוריה (storage.googleapis.com/Bucket) או בסוג המשאב של האובייקט (storage.googleapis.com/Object). אם בקטגוריה כלשהי בפרויקט יש תנאי IAM שמשתמש באחד מסוגי המשאבים האלה, אי אפשר ליצור תיקיות מנוהלות באף אחת מהקטגוריות בפרויקט הזה, גם אם התנאי יוסר בהמשך.

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

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

הגדרת הנתונים כציבוריים

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

פתרון: יכול להיות שאילוצים של מדיניות הארגון מונעים ממך להפוך את הנתונים לציבוריים. לדוגמה, האילוץ Domain Restricted Sharing (constraints/iam.allowedPolicyMemberDomains) מגביל את שיתוף המשאבים על סמך הדומיין של הארגון. אם יש כשלים במדיניות הארגון, צריך לפנות לאדמין כדי לקבל הרשאות ברמת הפרויקט או הקטגוריה, כדי לאפשר שיתוף משאבים על ידי עריכת מדיניות הארגון עבור הארגון, התיקייה או משאב הפרויקט. אם השגיאה הזו ממשיכה להופיע אחרי ששיניתם את כללי המדיניות של הארגון, יכול להיות שתצטרכו לחכות כמה דקות עד שהשינוי ייכנס לתוקף.

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

הפתרון: מוודאים שיש לכם הרשאת storage.buckets.setIamPolicy או הרשאת storage.objects.setIamPolicy. את ההרשאות האלה מקבלים גם בתפקיד אדמין של Storage (roles/storage.admin). אם יש לכם הרשאה storage.buckets.setIamPolicy או הרשאה storage.objects.setIamPolicy ובכל זאת מופיעה הודעת שגיאה, יכול להיות שהגדרת מניעה של גישה ציבורית חלה על הקטגוריה, ולכן לא מתאפשרת גישה ל-allUsers או ל-allAuthenticatedUsers. מניעת גישה ציבורית מוגדרת ישירות בקטגוריה או במדיניות הארגון שמוגדרת ברמה גבוהה יותר.

זמן אחזור

ריכזנו כאן כמה בעיות נפוצות שקשורות לזמן האחזור. בנוסף, בGoogle Cloud לוח הבקרה של Service Health אפשר למצוא מידע על אירועים שמשפיעים על Google Cloud שירותים כמו Cloud Storage.

זמן אחזור של העלאה או הורדה

הבעיה: זמן אחזור ארוך יותר בזמן ההעלאה או ההורדה.

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

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

  • מגבלות קלט/פלט בדיסק: יכול להיות שההשפעה על הביצועים נגרמת בגלל קלט/פלט בדיסק המקומי.

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

    • במקרים המתאימים, מקודד ה-DNS של הסביבה המושפעת צריך להשתמש בפרוטוקול EDNS(0) כדי שבקשות מהסביבה ינותבו דרך ממשק קצה מתאים של Google ‏(GFE).

זמן אחזור של CLI או של ספריית לקוח

הבעיה: בגישה ל-Cloud Storage באמצעות Google Cloud CLI או אחת מספריות הלקוח, זמן האחזור ארוך יותר.

הפתרון: במקרים של בקשות שכדאי לנסות לבצע שוב, ה-CLI של gcloud וספריות הלקוח מנסים שוב באופן אוטומטי. הניסיונות האלה עלולים בסופו של דבר להאריך את זמן האחזור אצל משתמש הקצה. משתמשים במדד Cloud Monitoring storage.googleapis.com/api/request_count כדי לבדוק אם ב-Cloud Storage מוצג באופן עקבי קוד תגובה של ניסיון חוזר כמו 429 או 5xx.

שרתי Proxy

הבעיה: אתם מתחברים דרך שרת proxy. מה עושים?

הפתרון: כדי לגשת ל-Cloud Storage דרך שרת proxy, צריך לאפשר גישה לדומיינים הבאים:

  • accounts.google.com ליצירת אסימוני אימות OAuth2
  • oauth2.googleapis.com לביצוע החלפות אסימוני OAuth2
  • *.googleapis.com לבקשות אחסון

אם שרת ה-proxy או מדיניות האבטחה לא תומכים בהוספה לרשימת ההיתרים לפי דומיין, אלא רק בהוספה לרשימת ההיתרים לפי חסימת רשת IP, מומלץ מאוד להגדיר את שרת ה-proxy לכל טווחי כתובות ה-IP של Google. תוכלו למצוא את טווחי הכתובות בעזרת שאילתות על נתוני WHOIS ב-ARIN. מומלץ לבדוק מדי פעם את הגדרות לשרת proxy כדי לוודא שהן תואמות לכתובות ה-IP של Google.

לא מומלץ להגדיר לשרת ה-proxy את כתובות ה-IP הספציפיות שמתקבלות מחיפושים חד-פעמיים של oauth2.googleapis.com ו-storage.. הגישה לשירותי Google היא באמצעות שמות DNS, שממופים למספר גדול של כתובות IP שיכולות להשתנות עם הזמן. לכן הגדרת שרת ה-proxy על סמך חיפוש חד-פעמי עלולה לגרום לכשלים בהתחברות ל-Cloud Storage.

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

המאמרים הבאים