שימוש בשכפול בין קטגוריות

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

סקירה כללית על רפליקציה בין קטגוריות

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

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

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

כדי לשכפל אובייקטים בין קטגוריות, משתמשים ב-Storage Transfer Service. כדי לקבל התראות על שינויים בקטגוריות המקור והיעד, משתמשים ב-Pub/Sub. אפשר להפעיל רפליקציה בין קטגוריות בקטגוריות חדשות שיוצרים ובקטגוריות קיימות. אפשר לשכפל את רוב האובייקטים תוך כמה דקות, אבל שכפול של אובייקטים שגדולים מ-GiB אחד יכול להימשך כמה שעות.

מגבלות

  • אי אפשר להשתמש בשמות בהתאמה אישית למשימות של שכפול בין קטגוריות. בקשות ליצירה שמכילות ערך בשדה name מחזירות שגיאה.

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

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

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

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

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

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

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

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

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

הפעלת Storage Transfer Service API

אם עדיין לא עשיתם זאת, מפעילים את Storage Transfer Service API.

קבלת התפקידים הנדרשים

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

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

ההרשאות הנדרשות

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

  • יצירה, הרצה ועדכון של משימות:
    • storagetransfer.jobs.create
    • storagetransfer.jobs.get
    • storagetransfer.jobs.list
    • storagetransfer.jobs.run
    • storagetransfer.jobs.update
  • מחיקת משרות: storagetransfer.jobs.delete

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

מתן התפקידים הנדרשים

כדי לשכפל אובייקטים מקטגוריית המקור לקטגוריית היעד, משתמשים ב-Storage Transfer Service. כדי לקבל התראות על שינויים בקטגוריית המקור, משתמשים ב-Pub/Sub.

כדי ששכפול בין קטגוריות יוכל להשתמש בשירותים האלה, צריך לתת את ההרשאות הנדרשות לחשבון השירות שמשמש את Storage Transfer Service לשכפול נתונים, וגם לסוכן השירות שמשמש את Pub/Sub לכתיבת התראות.

הקצאת התפקידים הנדרשים ל-Storage Transfer Service

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

  • סוכן השירות של Storage Transfer Service, שנוצר ומנוהל באופן אוטומטי על ידי Google. כתובת האימייל של סוכן השירות הזה היא בפורמט project-PROJECT_NUMBER@storage-transfer-service.. כדי לקבל את כתובת האימייל של סוכן השירות של Storage Transfer Service, אתם יכולים להשתמש ב-API של Storage Transfer Service googleServiceAccounts.get.

או:

  • חשבון שירות שמנוהל על ידי משתמש. כתובת האימייל של חשבון השירות הזה היא בפורמט SERVICE_ACCOUNT_NAME@PROJECT_ID.. אתם יכולים ליצור חשבון שירות משלכם ולתת לו את ההרשאות שנדרשות כדי לשכפל את הנתונים.

    במאמר הקצאת הרשאות של סוכן שירות לחשבון שירות בניהול המשתמש מוסבר איך להשתמש בחשבון שירות בניהול המשתמש עם Storage Transfer Service. יש הרשאות נוספות שנדרשות מעבר לאלה שמופיעות ברשימות הבאות. באופן ספציפי, צריך לתת לסוכן השירות גישה לחשבון השירות שמנוהל על ידי המשתמש, על ידי הקצאת התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator). מידע נוסף זמין במאמר מתן גישה לסוכן השירות.

כדי לשכפל את האובייקטים ולהגדיר התראות Pub/Sub לקטגוריית המקור, סוכן השירות של Storage Transfer Service או חשבון השירות של המשתמש צריכים את ההרשאות הבאות:

ההרשאות הנדרשות

בפרויקט המקור צריך לתת את ההרשאות הבאות:

  • pubsub.topics.create
  • pubsub.subscriptions.create
  • pubsub.subscriptions.consume

צריך לתת את ההרשאות הבאות בקטגוריית המקור:

  • storage.buckets.get
  • storage.buckets.update
  • storage.objects.get

צריך לתת את ההרשאות הבאות בקטגוריית היעד:

  • storage.buckets.get
  • storage.objects.create
  • storage.objects.get

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

  • תפקיד עריכה ב-Pub/Sub‏ (roles/pubsub.editor) בפרויקט המקור
  • התפקידים "בעלים של קטגוריית אחסון מדור קודם" (roles/storage.legacyBucketOwner) ו"צפייה באובייקטים של אחסון" (roles/storage.objectViewer) בקטגוריית המקור
  • התפקידים Storage Object User (roles/storage.objectUser) ו-Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) בקטגוריית היעד

הקצאת התפקידים הנדרשים ל-Pub/Sub

ב-Cloud Storage משתמשים בסוכן שירות כדי לנהל את התראות Pub/Sub. כתובת האימייל של סוכן השירות הזה היא בפורמט service-PROJECT_NUMBER@gs-project-accounts..

כדי להגדיר את Pub/Sub ולפרסם הודעות בנושא, סוכן השירות של Cloud Storage צריך את ההרשאות הבאות:

ההרשאות הנדרשות
  • ‫pubsub.topics.publish בנושא Pub/Sub

אפשר לתת את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או באמצעות התפקיד המוגדר מראש הבא:

  • פרסום הודעות ב-Pub/Sub‏ (roles/pubsub.publisher) בפרויקט המקור

יצירת משימת רפליקציה

המסוף

במאמר יצירת משימת רפליקציה באמצעות מסוף Google Cloud מוסבר איך יוצרים משימת רפליקציה באמצעות מסוף Google Cloud .

שורת הפקודה

כשמשתמשים ב-Google Cloud CLI, אפשר ליצור משימת רפליקציה לקטגוריות קיימות.

כדי ליצור משימת רפליקציה, משתמשים בפקודה gcloud alpha transfer jobs create עם הדגל --replication:

gcloud alpha transfer jobs create gs://SOURCE_BUCKET_NAME gs://DESTINATION_BUCKET_NAME --replication

מחליפים את:

  • ‫SOURCE_BUCKET_NAME בשם של קטגוריית המקור שרוצים לשכפל. לדוגמה, my-source-bucket.

  • ‫DESTINATION_BUCKET_NAME בשם של קטגוריית היעד. לדוגמה, my-destination-bucket.

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

ממשקי API בארכיטקטורת REST

‫API בפורמט JSON

כשמשתמשים ב-API בפורמט JSON, אפשר ליצור משימת רפליקציה לקטגוריות קיימות.

  1. להתקין ולהפעיל את ה-CLI של gcloud, שמאפשר ליצור אסימון גישה לכותרת Authorization.

  2. יוצרים קובץ JSON שמכיל אובייקט TransferJob עם משאב ReplicationSpec מאותחל:

    TransferJob {
 ReplicationSpec: {
   "gcsDataSource": {
     "bucketName": "SOURCE_BUCKET_NAME"
   },
   "gcsDataSink" {
     "bucketName": "DESTINATION_BUCKET_NAME"
   },
   "objectConditions": {
   },
   "transferOptions": {
     "overwriteWhen": "OVERWRITE_OPTION"
   }
 }
 ...
}

    מחליפים את:

    • ‫SOURCE_BUCKET_NAME בשם של קטגוריית המקור שמכילה את האובייקטים שרוצים לשכפל. לדוגמה, example-source-bucket.

    • ‫DESTINATION_BUCKET_NAME בשם של קטגוריית היעד שאליה ישוכפלו האובייקטים. לדוגמה, example-destination-bucket.

    • ‫OVERWRITE_OPTION עם אפשרות להחלפת אובייקטים קיימים בקטגוריית היעד כתוצאה ממשימת רפליקציה, שיכולה לקרות כשאובייקט היעד ואובייקט המקור הם בעלי אותו שם. הערך חייב להיות אחד מהבאים:

      • ‫ALWAYS: תמיד להחליף אובייקטים בקטגוריית היעד

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

      • ‫NEVER: אף פעם לא להחליף אובייקטים בקטגוריית היעד

    חשוב לזכור שהשדה name לא נתמך במשימות של שכפול בין קטגוריות.

  3. משתמשים ב-cURL כדי לשלוח קריאה ל-Storage Transfer Service API בארכיטקטורת REST באמצעות בקשת transferJobs.create:

    curl -X POST --data-binary @JSON_FILE_NAME \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://storagetransfer.googleapis.com/v1/transferJobs"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫JSON_FILE_NAME הוא השם של קובץ ה-JSON שיצרתם בשלב 2.

כדי לבדוק את הסטטוס של משימת הרפליקציה, צפו ביומני שירות של Storage Transfer Service ב-Cloud Logging.

הצגת רשימה של משימות שכפול

המסוף

במאמר הצגת רשימה של משימות רפליקציה באמצעות מסוף Google Cloud מוסבר איך להציג את הרשימה באמצעות מסוף Google Cloud .

שורת הפקודה

משתמשים בפקודה gcloud alpha transfer jobs list עם הדגל --job-type:

gcloud alpha transfer jobs list --job-type=replication

ממשקי API בארכיטקטורת REST

‫API בפורמט JSON

  1. להתקין ולהפעיל את ה-CLI של gcloud, שמאפשר ליצור אסימון גישה לכותרת Authorization.

  2. משתמשים ב-cURL כדי לשלוח קריאה ל-Storage Transfer Service API בארכיטקטורת REST באמצעות בקשת transferJobs.list:

    curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://storagetransfer.googleapis.com/v1/transferJobs"

הצגת משימת רפליקציה

המסוף

במאמר הצגת משימת רפליקציה באמצעות מסוף Google Cloud מוסבר איך מציגים משימת רפליקציה במסוף Google Cloud .

שורת הפקודה

משתמשים בפקודה gcloud alpha transfer jobs describe:

gcloud alpha transfer jobs describe JOB_NAME

מחליפים את:

ממשקי API בארכיטקטורת REST

‫API בפורמט JSON

  1. להתקין ולהפעיל את ה-CLI של gcloud, שמאפשר ליצור אסימון גישה לכותרת Authorization.

  2. משתמשים ב-cURL כדי לשלוח קריאה ל-API בארכיטקטורת REST של Storage Transfer Service באמצעות בקשת transferJobs.get:

    curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://storagetransfer.googleapis.com/v1/transferJobs/JOB_NAME"

    מחליפים את:

עדכון של משימת רפליקציה

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

  • תיאור משימת השכפול
  • ההגדרה להרצת משימת רפליקציה
  • הגדרת ההתראות שפורסמו ב-Pub/Sub
  • התנהגות הרישום ביומן של פעולות משימת הרפליקציה

  • הסטטוס של משימת הרפליקציה (אם היא מופעלת, מושבתת או נמחקה)

המסוף

במאמר עדכון משימת רפליקציה באמצעות מסוף Google Cloud מוסבר איך לעדכן משימת רפליקציה באמצעות מסוף Google Cloud .

שורת הפקודה

משתמשים בפקודה gcloud alpha transfer jobs update עם הדגלים ששולטים במאפיינים של משימת הרפליקציה שרוצים לעדכן. רשימה של דגלים אפשריים מופיעה במאמרי העזרה של gcloud alpha transfer jobs update.

לדוגמה, כדי לעדכן את התנהגות החלפת האובייקטים של משימת הרפליקציה, מריצים את הפקודה gcloud alpha transfer jobs update עם הדגל --overwrite-when:

gcloud alpha transfer jobs update JOB_NAME --overwrite-when=OVERWRITE_OPTION

מחליפים את:

  • ‫JOB_NAME במזהה הייחודי של משימת הרפליקציה. לדוגמה, 1234567890. כדי למצוא את המזהה של משימת ההעברה, מציגים רשימה או מציגים את משימת ההעברה.

  • ‫OVERWRITE_OPTION עם אפשרות להחלפת אובייקטים קיימים בקטגוריית היעד כתוצאה ממשימת רפליקציה, שיכולה לקרות כשאובייקט היעד ואובייקט המקור הם בעלי אותו שם. הערך חייב להיות אחד מהבאים:

    • ‫always: תמיד להחליף את אובייקטי היעד.

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

    • ‫never: אף פעם לא להחליף אובייקטים ביעד.

ממשקי API בארכיטקטורת REST

‫API בפורמט JSON

  1. להתקין ולהפעיל את ה-CLI של gcloud, שמאפשר ליצור אסימון גישה לכותרת Authorization.

  2. יוצרים קובץ JSON שמכיל את המבנה הבא, שכולל את השדות של האובייקט TransferJob שרוצים לעדכן:

    {
 "projectId": string,
 "transferJob": {
   object (TransferJob)
 },
   "updateTransferJobFieldMask": UPDATE_MASK
}

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫object (TransferJob) מוחלף בשדות של משימת הרפליקציה שרוצים לעדכן. מידע נוסף מופיע בייצוג המשאבים של TransferJob.

    • ‫UPDATE_MASK היא רשימה מופרדת בפסיקים של שמות השדות שרוצים לעדכן. הערכים יכולים להיות אחד או יותר מהבאים: description,‏ transferSpec,‏ notificationConfig,‏ loggingConfig,‏ status.

    למידע נוסף על שמות השדות שאפשר לכלול, ראו גוף הבקשה של transferJobs.patch.

  3. משתמשים ב-cURL כדי לשלוח קריאה ל-Storage Transfer Service API בארכיטקטורת REST באמצעות בקשת transferJobs.patch:

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://storagetransfer.googleapis.com/v1/transferJobs/JOB_NAME"

    מחליפים את:

מחיקת משימת רפליקציה

המסוף

במאמר מחיקת משימת רפליקציה באמצעות מסוף Google Cloud מוסבר איך למחוק משימת רפליקציה באמצעות מסוף Google Cloud .

שורת הפקודה

משתמשים בפקודה gcloud alpha transfer jobs delete:

gcloud alpha transfer jobs delete JOB_NAME

מחליפים את:

ממשקי API בארכיטקטורת REST

‫API בפורמט JSON

  1. להתקין ולהפעיל את ה-CLI של gcloud, שמאפשר ליצור אסימון גישה לכותרת Authorization.

  2. משתמשים ב-cURL כדי לשלוח קריאה ל-Storage Transfer Service API בארכיטקטורת REST באמצעות בקשת transferJobs.delete:

    curl -X DELETE \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
"https://storagetransfer.googleapis.com/v1/transferJobs/JOB_NAME"

    מחליפים את: