אימות נתונים וזיהוי שינויים

‫Cloud Storage מעודד אתכם לבצע אימות של הנתונים שאתם מעבירים לקטגוריות או מהן. בדף הזה מתוארות שיטות מומלצות לביצוע אימותים באמצעות סיכום ביקורת (checksum) מסוג CRC32C או מסוג MD5, ומתואר אלגוריתם זיהוי השינויים שמשמש בפקודה gcloud storage rsync.

הגנה מפני פגיעה בנתונים באמצעות גיבובים

במהלך העלאה לענן או במהלך ההורדה ממנו, הנתונים עלולים להיפגם במגוון דרכים:

  • שגיאות זיכרון במחשבי לקוח או שרת, או בנתבים בדרך
  • באגים בתוכנה (לדוגמה, בספרייה שבה לקוחות משתמשים)
  • שינויים בקובץ המקור כשמשך ההעלאה ארוך

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

אימות בצד הלקוח

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

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

  • תשובה שמכילה רק חלק מנתוני האובייקט, שמתקבלת כשמבצעים בקשת range. ב-Cloud Storage מומלץ לשלוח בקשות לטווח חלקי של אובייקט רק כדי להפעיל מחדש את ההורדה של אובייקט שלם אחרי ההיסט האחרון שהתקבל, כי במקרה כזה אפשר לחשב ולאמת את סיכום הביקורת (checksum) כשההורדה המלאה מסתיימת.

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

אימות בצד השרת

Cloud Storage מבצע אימות בצד השרת במקרים הבאים:

  • כשמבצעים בקשה להעתקה או לשכתוב בתוך Cloud Storage.

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

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

    • בבקשות רלוונטיות ל-API בפורמט XML, מספקים את סכומי הביקורת באמצעות הכותרת x-goog-hash. ‫API בפורמט XML מקבל גם את הכותרת Content-MD5 הרגילה של HTTP (ראו מפרט).

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

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

אימות של Google Cloud CLI

ב-Google Cloud CLI, מתבצע אימות של נתונים שמועתקים לקטגוריה של Cloud Storage או ממנה. הכלל הזה חל על פקודות cp, mv ו-rsync. אם סיכום הביקורת (checksum) של נתוני המקור לא תואם לסיכום הביקורת (checksum) של נתוני היעד, ה-CLI של gcloud ימחק את העותק הלא תקין וידפיס הודעת אזהרה. זה קורה לעיתים רחוקות מאוד. אם זה קורה, צריך לנסות את הפעולה שוב.

האימות האוטומטי מתרחש אחרי שהאובייקט עצמו מסתיים, כך שאובייקטים לא חוקיים גלויים למשך 1-3 שניות לפני שהם מזוהים ונמחקים. בנוסף, יש סיכוי שה-CLI של gcloud יופסק אחרי שההעלאה תסתיים אבל לפני שהוא יבצע את האימות, וכך האובייקט הלא תקין יישאר במקומו. אפשר להימנע מהבעיות האלו כשמעלים קבצים בודדים ל-Cloud Storage באמצעות אימות בצד השרת, שמתרחש כשמשתמשים בדגל --content-md5.

שינוי שזוהה ב-rsync

הפקודה gcloud storage rsync יכולה גם להשתמש בסכומי ביקורת מסוג MD5 או CRC32C כדי לקבוע אם יש הבדל בין הגרסה של אובייקט שנמצא במקור לבין הגרסה שנמצאת ביעד. הפקודה משווה את סכומי הביקורת במקרים הבאים:

  • המקור והיעד הם שניהם קטגוריות בענן, ולאובייקט יש סיכום ביקורת (checksum) מסוג MD5 או CRC32C בשתי הקטגוריות.

  • לאובייקט אין זמן שינוי קובץ (mtime) במקור או ביעד.

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

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

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