סנכרון מ-Cloud Storage

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

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

לקבלת תמיכה לגבי שיקופים פעילים של Cloud Storage, פנו אל [e-mail].

השוואה בין שיקוף של Cloud Storage לבין העברות נתונים על פי דרישה

ב-Managed Lustre יש שני מנגנונים להעברת נתונים באמצעות Cloud Storage:

תכונה	שרתי מראה של Cloud Storage	העברות נתונים על פי דרישה
כיוון	‫Cloud Storage ל-Managed Lustre	‫Cloud Storage ל-Managed Lustre ‫Managed Lustre ל-Cloud Storage
טריגר	מבוסס-אירועים; מסתנכרן אוטומטית כשיוצרים, מעדכנים ומוחקים אובייקטים	גלילה ידנית
מרחב שמות היררכי	לא נתמך	יש תמיכה ומומלץ להשתמש בהן כדי להאיץ את מהירות ההעברה
קטגוריות של Rapid Storage	לא נתמך	לא נתמך

מידע על העברות על פי דרישה מופיע במאמר העברת נתונים אל Cloud Storage וממנו.

איך פועל מאגר נתונים חלופי ב-Cloud Storage

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

סנכרון ראשוני

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

רפליקציה רציפה מבוססת-אירועים

אחרי הסנכרון הראשוני, שירות השיקוף מאזין להתראות מהקטגוריה ומשכפל את השינויים.

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

• כשיוצרים אובייקט חדש ב-Cloud Storage, נוצר באופן אוטומטי הקובץ התואם ב-Managed Lustre.

• אם משנים אובייקט קיים ב-Cloud Storage, הקובץ ב-Managed Lustre מוחלף וכל השינויים המקומיים שבוצעו במערכת הקבצים נמחקים.

• שינויים במאפייני מטא-נתונים מותאמים אישית של POSIX באובייקטים של Cloud Storage, כמו UID,‏ GID, מצב או mtime, מתעדכנים בקובץ Managed Lustre התואם.

• כברירת מחדל, כשמוחקים אובייקט ב-Cloud Storage, הקובץ התואם נמחק ב-Managed Lustre. אפשר לשנות את ההתנהגות הזו באמצעות הדגל --deleted-files-retained. ספריות אם ריקות נשארות במערכת הקבצים אחרי שהקובץ האחרון שמתחתיהן נמחק.

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

• אם מוחקים קובץ מסונכרן ב-Managed Lustre, האובייקט התואם ב-Cloud Storage לא נמחק.

מהירויות העברה

מהירויות ההעברה הבאות חלות על מאגרי נתונים מקבילים ב-Cloud Storage, שהקטגוריות והמכונות שלהם נמצאות באותו אזור ב- Google Cloud :

• בסנכרון הראשוני, הנתונים הקיימים מועתקים בקצב של עד 100GBps לקבצים שגדולים מ-32MB, ועד 10,000 אובייקטים לשנייה לקבצים קטנים.

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

  • קבצים גדולים של 10MB או יותר מועברים בקצב העברה מקסימלי של עד 3.5GBps.
  • קבצים קטנים של 4KB או פחות מועברים בקצב של עד 4,900 אובייקטים לשנייה.

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

מהירות ההעברה מוגבלת על ידי:

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

• רוחב הפס של תעבורת הנתונים היוצאת (egress) של Cloud Storage, שמוגבל ל-‎200 Gbps או ל-‎25 GBps לכל אזור בכל פרויקט. כדי לקבל רוחב פס גדול יותר לתעבורת נתונים יוצאת, בקשו להגדיל את המכסה.

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

תמחור

על מאגר מראה ב-Cloud Storage חלים חיובים רגילים של Cloud Storage, שמחויבים בפרויקט שמכיל את קטגוריית המקור:

• בסנכרון הראשוני מתבצעות פעולות רשימה מסוג Class A ופעולות קריאה מסוג Class B בקטגוריית המקור, וברפליקציה הרציפה מתבצעות פעולות קריאה מסוג Class B, שכרוכות בחיובים על פעולות ב-Cloud Storage.
• סנכרון נתונים מקטגוריית מקור באזור שונה מהמכונה של Managed Lustre כרוך בחיובים על העברת נתונים בין אזורים.

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

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

• מכונה של Managed Lustre במצב ACTIVE.
• קטגוריה קיימת של Cloud Storage שתשמש כמקור לשיקוף. אין תמיכה בקטגוריות שמופעל בהן מרחב שמות היררכי, בקטגוריות של Rapid Storage ובקטגוריות שמופעל בהן Requester Pays.

הרשאות, תפקידים ומשאבים נדרשים

כדי ליצור ולנהל את המראות של Cloud Storage, צריך את ההרשאות, התפקידים והמשאבים הבאים ב-IAM.

הרשאות של משתמשים

כדי ליצור ולנהל עותקי ראי, חשבון המשתמש או חשבון השירות שלכם צריכים את התפקיד "אדמין של Managed Lustre",‏ roles/lustre.admin.

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

• lustre.mirrors.create כדי ליצור מראה.
• lustre.mirrors.get כדי לתאר מראה.
• ‫lustre.mirrors.list כדי להציג רשימה של שרתי מראה.
• ‫lustre.mirrors.update כדי לעדכן מראה.
• ‫lustre.mirrors.delete כדי למחוק מראה.

הפעלה של סוכן השירות של Cloud Storage

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

gcloud storage service-agent --project=PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

הרשאות של סוכן שירות ב-Managed Lustre

סוכן השירות של Managed Lustre שמנוהל על ידי Google צריך גישה לקטגוריה של Cloud Storage. במאמר סוכן השירות של Managed Lustre מוסבר איך למצוא או להפעיל את הזהות של סוכן השירות.

לסוכן השירות נדרשות ההרשאות הבאות בקטגוריה של Cloud Storage:

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

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

gcloud iam roles create lustreMirrorUser \
  --project=PROJECT_ID \
  --title="Lustre mirror user" \
  --permissions=storage.buckets.get,storage.buckets.update,storage.objects.get,storage.objects.list

מקצים את התפקיד בהתאמה אישית לסוכן השירות של Managed Lustre בקטגוריית המקור:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member="serviceAccount:[e-mail]" \
  --role="projects/PROJECT_ID/roles/lustreMirrorUser"

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫BUCKET_NAME: השם של קטגוריית המקור ב-Cloud Storage.
• ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .

יצירת מראה ב-Cloud Storage

אפשר ליצור שיקוף אחד של Cloud Storage לכל מכונה של Managed Lustre.

אי אפשר ליצור עותק ראי ב-Cloud Storage בזמן שמתבצעת פעולת ייבוא או ייצוא במכונה.

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

gcloud

מריצים את הפקודה mirrors create:

gcloud lustre instances mirrors create MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION \
  --direction=from-cloud-storage \
  --gcs-path-uri="gs://BUCKET_NAME/PREFIX/" \
  --lustre-path="/LUSTRE_DIRECTORY"

כאשר:

• ‫MIRROR_NAME הוא השם של משאב השיקוף הזה. השם צריך להיות באורך של 1 עד 63 תווים, לכלול רק אותיות קטנות, מספרים ומקפים, להתחיל באות ולהסתיים באות או במספר.
• ‫INSTANCE_ID הוא המזהה של המכונה ב-Managed Lustre.
• ‫LOCATION הוא האזור של המכונה. לדוגמה, us-central1-a.
• ‫--direction מציין את כיוון השיקוף. הערך חייב להיות from-cloud-storage.
• ‫--gcs-path-uri הוא קטגוריה של Cloud Storage והקידומת האופציונלית של האובייקט. אם מציינים קידומת של אובייקט, הנתיב חייב להסתיים בלוכסן: gs://<var>BUCKET_NAME</var>/<var>PREFIX</var>/.
• ‫--lustre-path היא ספריית היעד במערכת הקבצים של Managed Lustre. הנתיב חייב להיות מוחלט ולהתחיל ב-/, לדוגמה /data או /data/subdir. ברירת המחדל היא תיקיית השורש, /. אם הספרייה שצוינה לא קיימת, היא נוצרת.

אפשר להשתמש בפרמטרים האופציונליים הבאים:

• ‫--deleted-files-retained או --no-deleted-files-retained: קובע אם קבצים שנמחקו ב-Cloud Storage יישמרו ב-Managed Lustre. ברירת המחדל היא --no-deleted-files-retained.
• ‫--description=DESCRIPTION_TEXT: תיאור אופציונלי של המאגר.

REST

שולחים בקשת POST ל-method‏ instances.mirrors.create:

POST https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors?mirrorId=MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "gcsPath": {
    "uri": "gs://BUCKET_NAME/PREFIX/"
  },
  "lustrePath": {
    "path": "/LUSTRE_DIRECTORY"
  },
  "direction": "FROM_CLOUD_STORAGE"
}

כאשר:

• ‫PROJECT_ID הוא מזהה הפרויקט ב- Google Cloud .
• ‫LOCATION הוא האזור של המכונה ב-Managed Lustre. לדוגמה, us-central1-a.
• ‫INSTANCE_ID הוא מזהה המכונה.
• ‫MIRROR_NAME הוא השם של משאב השיקוף. השם צריך להיות באורך של 1 עד 63 תווים, לכלול רק אותיות קטנות, מספרים ומקפים, להתחיל באות ולהסתיים באות או במספר.
• ‫gcsPath מכיל שדה uri עם קטגוריה של Cloud Storage ותחילית אופציונלית של אובייקט. אם מציינים קידומת של אובייקט, הנתיב חייב להסתיים בלוכסן: gs://<var>BUCKET_NAME</var>/<var>PREFIX</var>/.
• ‫lustrePath היא ספריית היעד במערכת הקבצים של Managed Lustre. הנתיב חייב להיות מוחלט ולהתחיל ב-/, לדוגמה /data או /data/subdir. ברירת המחדל היא תיקיית השורש, /. אם הספרייה שצוינה לא קיימת, היא נוצרת.
• ‫direction מציין את כיוון השיקוף. הערך חייב להיות FROM_CLOUD_STORAGE.

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

• ‫deletedFilesRetained: מגדירים את הערך true כדי לשמור קבצים ב-Managed Lustre אחרי שהקבצים התואמים נמחקים מ-Cloud Storage. ברירת המחדל היא false.
• ‫description: תיאור אופציונלי של המאגר המראה.

מאפייני קבצים

כשמעתיקים קובץ מקטגוריה של Cloud Storage למכונה של Managed Lustre, מאפייני הקובץ במכונה של Managed Lustre מוגדרים באחת משתי דרכים:

• אם לאובייקט ב-Cloud Storage יש מטא-נתונים בהתאמה אישית, כמו שמתואר בייצוא נתונים:
  • מזהה המשתמש, מזהה הקבוצה, המצב ו-mtime של הקובץ מוגדרים על סמך המטא-נתונים המותאמים אישית של האובייקט.
  • הערך של atime בקובץ זהה לערך של mtime.
• אם לאובייקט ב-Cloud Storage אין את המטא-נתונים בהתאמה אישית:
  • ה-UID וה-GID של הקובץ מוגדרים ל-0 (root).
  • מצב הקובץ מוגדר ל-rwxr-xr-x (755).
  • השדות atime ו-mtime של הקובץ מוגדרים לזמן היצירה של האובייקט ב-Cloud Storage.

בשני המקרים:

• הערך של ctime של קובץ מוגדר לזמן שבו הקובץ נכתב במכונה.
• השדות atime,‏ ctime ו-mtime של ספרייה מוגדרים לזמן שבו הספרייה נוצרה במכונה.

ניהול של מאגרי Cloud Storage מועתקים

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

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

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

gcloud

gcloud lustre instances mirrors list \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

שולחים בקשת GET ל-method‏ instances.mirrors.list:

GET https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors
Authorization: Bearer YOUR_ACCESS_TOKEN

תיאור של מראה

כדי לראות את ההגדרות ואת סטטוס הפעילות של מראה:

gcloud

gcloud lustre instances mirrors describe MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

שולחים בקשת GET ל-method‏ instances.mirrors.get:

GET https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN

מצבי שיקוף

השדה state שמוחזר על ידי הפקודות list ו-describe מדווח על המיקום של המאגר המועתק במחזור החיים שלו:

מדינה	תיאור
CREATING	המשאב לשיקוף נוצר.
INITIAL_SYNC	הסנכרון הראשוני מעתיק אובייקטים קיימים מ-Cloud Storage.
ACTIVE	התיקייה מסנכרנת את השינויים כשהם מתרחשים.
DELETING	השיקוף נמחק.

עדכון מראה

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

אי אפשר לשנות את הנתיבים של Cloud Storage ושל Managed Lustre. כדי להפנות את התיקייה לנתיב אחר, צריך למחוק את התיקייה וליצור אחת חדשה.

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

gcloud

gcloud lustre instances mirrors update MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION \
  --description="DESCRIPTION_TEXT"

REST

שולחים בקשת PATCH ל-method‏ instances.mirrors.patch עם פרמטר השאילתה updateMask:

PATCH https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME?updateMask=description
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "description": "DESCRIPTION_TEXT"
}

מחיקת מראה

כדי למחוק מראה:

gcloud

gcloud lustre instances mirrors delete MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

שולחים בקשת DELETE ל-method‏ instances.mirrors.delete:

DELETE https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN

מחיקת התיקייה המועתקת מפסיקה את הסנכרון העתידי בין Cloud Storage ל-Managed Lustre. קבצים שכבר הועתקו ל-Managed Lustre לא נמחקים כשמסירים את ה-mirror.

העברות קבצים שמתבצעות כשתיקיית סנכרון נמחקת, מבוטלות. העברות שלא הושלמו עשויות להשאיר קבצים זמניים בפורמט השם FILENAME.cloud_transfer.UUID.NUMBER.tmp בספריית המראה אחרי שהמראה נמחקת. אתם יכולים למחוק את הקבצים האלה.

צפייה ביומנים

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

היומנים מנותבים אל Cloud Logging למשאב lustre.googleapis.com/Instance, בשם היומן mirror.

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

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

1. נכנסים לדף Logs Explorer.

2. מזינים את השאילתה הבאה:

   resource.type="lustre.googleapis.com/Instance"
   logName="projects/PROJECT_ID/logs/lustre.googleapis.com%2Fmirror"
   resource.labels.instance_id="INSTANCE_ID"
   

פתרון בעיות

שגיאות מסוג PERMISSION_DENIED בקטגוריית המקור

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

1. מוודאים שסוכן השירות של Cloud Storage הופעל:

   gcloud storage service-agent --project=PROJECT_ID
   

2. מוודאים שלסוכן השירות של Managed Lustre ניתנו ההרשאות הנדרשות בקטגוריית המקור. למידע נוסף, קראו את המאמר מתן הרשאות לסוכן שירות.

שינויים ב-Cloud Storage לא משוכפלים ל-Managed Lustre

אם מצב השיקוף הוא ACTIVE אבל אובייקטים חדשים או כאלה ששונו ב-Cloud Storage לא מופיעים ב-Managed Lustre, ודאו שהגדרת ההתראות של הקטגוריה קיימת בקטגוריית המקור.

1. מציגים את ההתראות של הקטגוריה:

   gcloud storage buckets notifications list --bucket=BUCKET_NAME
   

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

   gcloud lustre instances mirrors delete MIRROR_NAME \
     --instance=INSTANCE_ID \
     --location=LOCATION
   

   אחרי שהמחיקה מסתיימת, יוצרים שיקוף חדש.

שגיאות שקשורות להתנגשויות בשמות

אם אתם שמים לב שחסרים קבצים ב-Managed Lustre אחרי שהוספתם אותם ל-Cloud Storage, בדקו ב-Cloud Logging אם יש שגיאות של התנגשות בשמות:

• אם לאובייקט שנוצר ב-Cloud Storage יש שם זהה לספרייה קיימת ב-Managed Lustre, ההעברה נכשלת עם השגיאה file exists והספרייה הקיימת לא מוחלפת. ההעברה שנכשלה משאירה קובץ זמני בפורמט השם FILENAME.cloud_transfer.UUID.NUMBER.tmp בספריית האם.
• אם אובייקט שנוצר ב-Cloud Storage מכיל תחילית של נתיב שתואמת לקובץ רגיל קיים ב-Managed Lustre, ההעברה נכשלת עם השגיאה not a directory והקובץ הקיים לא מוחלף. לדוגמה, אם models הוא קובץ קיים ב-Managed Lustre, העברת אובייקט בשם models/weights.bin מ-Cloud Storage תיכשל כי אי אפשר ליצור את הספרייה models/.

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

ABORTED: unable to queue the operation

אם קיבלתם את השגיאה ABORTED: unable to queue the operation כשניסיתם ליצור מראה או להפעיל משימת העברה לפי דרישה:

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

FILESYSTEM_NO_SPACE_ON_DEVICE

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