מעבר אל Google Cloud: העברת מערכי נתונים גדולים

Last reviewed 2024-11-13 UTC

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

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

המסמך הזה הוא חלק מסדרה של כמה חלקים בנושא מעבר אלGoogle Cloud:

מהי העברת נתונים?

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

העברת נתונים היא לא פשוטה כמו שהיא נשמעת

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

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

המסמך הזה נועד לעזור לכם להתחיל בתהליך העברה מוצלח.

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

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

שלב 1: הרכבת הצוות

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

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

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

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

שלב 2: איסוף הדרישות והמשאבים הזמינים

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

  1. מזהים את מערכי הנתונים שצריך להעביר.
    • בוחרים כלים כמו Knowledge Catalog כדי לארגן את הנתונים בקבוצות לוגיות שמועברות ומשמשות יחד.
    • כדאי לעבוד עם צוותים בארגון כדי לאמת או לעדכן את הקבוצות האלה.
  2. מזהים אילו מערכי נתונים אפשר להעביר.
    • חשוב לבדוק אם יש גורמים רגולטוריים, גורמי אבטחה או גורמים אחרים שמונעים העברה של מערכי נתונים מסוימים.
    • אם אתם צריכים לשנות חלק מהנתונים לפני שאתם מעבירים אותם (לדוגמה, כדי להסיר נתונים רגישים או לארגן מחדש את הנתונים), כדאי להשתמש במוצר לשילוב נתונים כמו Dataflow או Cloud Data Fusion, או במוצר לניהול תהליכי עבודה כמו Managed Service for Apache Airflow.
  3. לגבי קבוצות נתונים שאפשר להעביר, קובעים לאן להעביר כל קבוצת נתונים.
    • תעדו את אפשרות האחסון שבחרתם לאחסון הנתונים. בדרך כלל, מערכת האחסון המיועדת ב-Google Cloud היא Cloud Storage. גם אם תצטרכו פתרונות מורכבים יותר אחרי שהאפליקציות שלכם יפעלו, Cloud Storage הוא אפשרות אחסון עמידה וניתנת להתאמה.
    • להבין אילו כללי מדיניות של גישה לנתונים צריך לשמור אחרי ההעברה.
    • להחליט אם אתם צריכים לאחסן את הנתונים האלה באזורים ספציפיים.
    • תכננו את מבנה הנתונים ביעד. לדוגמה, האם הוא יהיה זהה למקור או שונה?
    • צריך להחליט אם אתם צריכים להעביר נתונים באופן קבוע.
  4. לגבי מערכי נתונים שאפשר להעביר, צריך לבדוק אילו משאבים זמינים להעברה שלהם.
    • זמן: מתי צריך להשלים את ההעברה?
    • עלות: מה התקציב הזמין לצוות ולעלויות ההעברה?
    • אנשים: מי זמין לבצע את ההעברה?
    • רוחב פס (להעברות אונליין): כמה מרוחב הפס הזמין של Google Cloud אפשר להקצות להעברה, ולכמה זמן?

לפני שמעריכים ובוחרים אפשרויות העברה בשלב הבא של התכנון, מומלץ לבדוק אם אפשר לשפר חלק כלשהו במודל ה-IT, כמו משילות מידע (data governance), ארגון ואבטחה.

מודל האבטחה שלכם

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

הארגון Google Cloud שלכם

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

‫Google Cloud מאורגן לפי פרויקטים. אפשר לקבץ פרויקטים בתיקיות, ואפשר לקבץ תיקיות בארגון. התפקידים מוגדרים ברמת הפרויקט, והרשאות הגישה מתווספות לתפקידים האלה ברמת הקטגוריה של Cloud Storage. המבנה הזה תואם למבנה ההרשאות של ספקים אחרים של מאגרי אובייקטים.

במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud תוכלו לקרוא על שיטות מומלצות לארגון המשאבים בפרויקטים של Google Cloud .

שלב 3: בחינת אפשרויות ההעברה

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

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

עלות

רוב העלויות שקשורות להעברת נתונים כוללות את הדברים הבאים:

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

זמן ההעברה

אחד מהדברים שמדגישים את מגבלות החומרה של רשתות במחשוב הוא העברת כמויות גדולות של נתונים. באופן אידיאלי, אפשר להעביר 1GB ב-8 שניות ברשת של 1Gbps. אם מגדילים את קבוצת הנתונים (לדוגמה, 100TB), זמן ההעברה הוא 12 ימים. העברה של מערכי נתונים עצומים יכולה לבחון את גבולות התשתית שלכם, ועלולה לגרום לבעיות בעסק.

כשאתם מעריכים כמה זמן תימשך ההעברה, כדאי להביא בחשבון את הגורמים הבאים:

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

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

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

הגדלת רוחב הפס של הרשת

הדרך להגדלת רוחב הפס של הרשת תלויה באופן החיבור ל-Google Cloud.

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

אם אתם מעבירים נתונים בין מרכז הנתונים הפרטי שלכם לביןGoogle Cloud, יש כמה גישות, למשל:

  • חיבור לאינטרנט ציבורי באמצעות API ציבורי
  • קישור ישיר בין רשתות שכנות (direct peering) באמצעות API ציבורי
  • ‫Cloud Interconnect באמצעות API פרטי

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

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

העברה אונליין לעומת העברה אופליין

אחת ההחלטות החשובות היא אם להשתמש בתהליך אופליין או אונליין להעברת הנתונים. כלומר, אתם צריכים לבחור בין העברה דרך רשת (Cloud Interconnect או האינטרנט הציבורי) לבין העברה באמצעות חומרת אחסון.

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

תרשים שמראה את הקשר בין גודל ההעברה למהירות ההעברה.

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

האפשרויות ש-Google מציעה

‫Google מציעה כמה כלים וטכנולוגיות שיעזרו לכם להעביר נתונים.

איך בוחרים בין אפשרויות ההעברה של Google

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

מאיפה אתם מעבירים את הנתונים תרחיש מוצרים מומלצים
ספק אחר של שירותי ענן (לדוגמה, Amazon Web Services או Microsoft Azure) כדי Google Cloud — Storage Transfer Service
‫Cloud Storage ל-Cloud Storage (שתי קטגוריות שונות) — Storage Transfer Service
מרכז הנתונים הפרטי שלך ל Google Cloud רוחב פס מספיק כדי לעמוד במועד האחרון של הפרויקט הפקודה gcloud storage
מרכז הנתונים הפרטי שלך ל Google Cloud רוחב פס מספיק כדי לעמוד במועד האחרון של הפרויקט ‫Storage Transfer Service לנתונים מקומיים
מרכז הנתונים הפרטי שלך ל Google Cloud אין מספיק רוחב פס כדי לעמוד במועד האחרון של הפרויקט Transfer Appliance

הפקודה gcloud storage להעברות קטנות יותר של נתונים מקומיים

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

הפקודה gcloud storage שימושית במיוחד בתרחישים הבאים:

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

‫Storage Transfer Service להעברות גדולות של נתונים מקומיים

בדומה לפקודה gcloud storage, גם Storage Transfer Service לנתונים מקומיים מאפשר העברות מאחסון של מערכת קובצי רשת (NFS) אל Cloud Storage. השירות Storage Transfer Service לנתונים מקומיים מיועד להעברות בקנה מידה גדול (עד פטה-בייטים של נתונים, מיליארדי קבצים). הוא תומך בהעתקות מלאות או בהעתקות מצטברות, ופועל בכל אפשרויות ההעברה שמפורטות למעלה בקטע בחירה בין אפשרויות ההעברה של Google. יש לו גם ממשק משתמש גרפי מנוהל, כך שגם משתמשים ללא ידע טכני יכולים להשתמש בו כדי להעביר נתונים (אחרי ההגדרה).

השירות Storage Transfer Service לנתונים מקומיים שימושי במיוחד בתרחישים הבאים:

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

כדי להגדיר את Storage Transfer Service לנתונים מקומיים, צריך להתקין תוכנה מקומית (שנקראת סוכנים) במחשבים שבמרכז הנתונים.

אחרי שמגדירים את Storage Transfer Service, אפשר להתחיל העברות במסוףGoogle Cloud על ידי ציון ספריית קובצי המקור, קטגוריית היעד והשעה או לוח הזמנים. ‫Storage Transfer Service סורק באופן רקורסיבי ספריות משנה וקבצים בספריית המקור, ויוצר אובייקטים עם שם תואם ב-Cloud Storage (האובייקט /dir/foo/file.txt הופך לאובייקט בקטגוריית היעד בשם /dir/foo/file.txt). אם Storage Transfer Service נתקל בשגיאות זמניות, הוא מנסה לבצע את ההעברה שוב באופן אוטומטי. בזמן שההעברות פועלות, אתם יכולים לעקוב אחרי מספר הקבצים שמועברים ואחרי מהירות ההעברה הכוללת, ולראות דוגמאות לשגיאות.

כשהשירות Storage Transfer Service מסיים העברה, הוא יוצר קובץ מופרד בטאבים (TSV) עם רשומה מלאה של כל הקבצים שהיו בשימוש וכל הודעות השגיאה שהתקבלו. הסוכנים עמידים בפני תקלות, כך שאם סוכן אחד מפסיק לפעול, ההעברה ממשיכה עם הסוכנים האחרים. הסוכנים גם מתעדכנים ומתקנים את עצמם, כך שלא צריך לדאוג לגבי תיקון הגרסה העדכנית או הפעלה מחדש של התהליך אם הוא נכשל בגלל בעיה לא צפויה.

דברים שצריך להביא בחשבון כשמשתמשים ב-Storage Transfer Service:

  • הגדרת הסוכן צריכה להיות זהה בכל מכונה. כל הנציגים צריכים לראות את אותן נקודות טעינה של מערכת קובצי רשת (NFS) באותו אופן (אותם נתיבים יחסיים). ההגדרה הזו נדרשת כדי שהמוצר יפעל.
  • ככל שיש יותר נציגים, כך המענה מהיר יותר. ההעברות מתבצעות באופן אוטומטי במקביל בכל הנציגים, ולכן מומלץ לפרוס הרבה נציגים כדי לנצל את רוחב הפס הזמין.
  • מגבלות רוחב פס יכולות להגן על עומסי העבודה שלכם. יכול להיות שעומסי עבודה אחרים משתמשים ברוחב הפס של מרכז הנתונים, לכן כדאי להגדיר מגבלה על רוחב הפס כדי שההעברות לא ישפיעו על הסכמי ה-SLA.
  • הקדישו זמן לבדיקת השגיאות. העברות גדולות עלולות לגרום לשגיאות שדורשות בדיקה. ב-Storage Transfer Service אפשר לראות דוגמה לשגיאות שנתקלתם בהן ישירות במסוף Google Cloud . במקרה הצורך, אתם יכולים לטעון את הרשומה המלאה של כל שגיאות ההעברה ל-BigQuery כדי לבדוק קבצים או להעריך שגיאות שנשארו גם אחרי ניסיונות חוזרים. יכול להיות שהשגיאות האלה נגרמו בגלל הפעלת אפליקציות שכתבו למקור בזמן שההעברה התרחשה, או שהשגיאות חושפות בעיה שצריך לפתור (לדוגמה, שגיאת הרשאות).
  • הגדרת Cloud Monitoring להעברות ארוכות. השירות Storage Transfer Service מאפשר ל-Monitoring לעקוב אחרי התקינות וקצב הנתונים של הסוכנים, כדי שתוכלו להגדיר התראות שיודיעו לכם כשהסוכנים לא פועלים או דורשים התייחסות. חשוב לטפל בכשלים של הסוכנים בהעברות שנמשכות כמה ימים או שבועות, כדי למנוע האטה משמעותית או הפרעות שעלולות לעכב את לוח הזמנים של הפרויקט.

‫Transfer Appliance להעברות גדולות יותר

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

השימוש ב-Transfer Appliance שימושי במיוחד בתרחישים הבאים:

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

אם בוחרים באפשרות הזו, חשוב לזכור:

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

שני הקריטריונים העיקריים שצריך להביא בחשבון כשמשתמשים ב-Transfer Appliance הם עלות ומהירות. עם קישוריות רשת סבירה (לדוגמה, 1Gbps), העברת 100TB של נתונים אונליין נמשכת יותר מ-10 ימים. אם הקצב הזה מתאים לכם, כנראה שהעברה אונליין היא פתרון טוב לצרכים שלכם. אם יש לכם חיבור של 100Mbps בלבד (או פחות, ממיקום מרוחק), אותה העברה תימשך יותר מ-100 ימים. בשלב הזה כדאי לשקול אפשרות של העברה אופליין, כמו Transfer Appliance.

קל מאוד להשיג מכשיר Transfer Appliance. במסוףGoogle Cloud , מבקשים מכשיר Transfer Appliance, מציינים את כמות הנתונים, ואז Google שולחת מכשיר אחד או יותר למיקום המבוקש. יש לכם מספר ימים להעביר את הנתונים למכשיר ("תיעוד נתונים") ולשלוח אותו בחזרה ל-Google.

Storage Transfer Service להעברות מענן לענן

‫Storage Transfer Service הוא שירות מנוהל וניתן להתאמה, שמאפשר להעביר באופן אוטומטי נתונים מעננים ציבוריים אחרים ל-Cloud Storage. לדוגמה, אתם יכולים להשתמש ב-Storage Transfer Service כדי להעביר נתונים מ-Amazon S3 ל-Cloud Storage.

ב-HTTP, אפשר לתת ל-Storage Transfer Service רשימה של כתובות URL ציבוריות בפורמט מסוים. בגישה הזו צריך לכתוב סקריפט שמספק את הגודל של כל קובץ בבייטים, יחד עם גיבוב MD5 בקידוד Base64 של תוכן הקובץ. לפעמים גודל הקובץ וה-hash זמינים באתר המקור. אם לא, אתם צריכים גישה מקומית לקבצים, ובמקרה כזה יכול להיות שיהיה קל יותר להשתמש בפקודה gcloud storage, כפי שמתואר למעלה.

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

אם אתם רוצים להעביר נתונים מענן אחר שלא נתמך על ידי Storage Transfer Service, אתם יכולים להשתמש בפקודה gcloud storage ממכונה וירטואלית שמתארחת בענן.

אבטחה

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

Product נתונים באחסון נתונים במעבר גישה להעברת מוצר
Transfer Appliance כל הנתונים מוצפנים במנוחה. הנתונים מוגנים באמצעות מפתחות שמנוהלים על ידי הלקוח. כל אחד יכול להזמין מכשיר, אבל כדי להשתמש בו צריך גישה למקור הנתונים.
הפקודה gcloud storage מפתחות גישה שנדרשים כדי לגשת ל-Cloud Storage, שמוצפן במנוחה. הנתונים נשלחים באמצעות HTTPS ומוצפנים בזמן ההעברה. כל אחד יכול להוריד ולהפעיל את Google Cloud CLI. כדי להעביר נתונים, צריכות להיות להם הרשאות לקטגוריות ולקבצים מקומיים.
‫Storage Transfer Service לנתונים מקומיים מפתחות גישה שנדרשים כדי לגשת ל-Cloud Storage, שמוצפן במנוחה. תהליך הנציג יכול לגשת לקבצים מקומיים בהתאם להרשאות של מערכת ההפעלה. הנתונים נשלחים באמצעות HTTPS ומוצפנים בזמן ההעברה. כדי לגשת לקטגוריות של Cloud Storage, צריכות להיות לכם הרשאות עריכה של אובייקטים.
Storage Transfer Service מפתחות גישה שנדרשים למשאבים שהם לא שלGoogle Cloud (לדוגמה, Amazon S3). כדי לגשת ל-Cloud Storage, שמוצפן במנוחה, נדרשים מפתחות גישה. הנתונים נשלחים באמצעות HTTPS ומוצפנים בזמן ההעברה. צריכות להיות לכם הרשאות IAM לחשבון השירות כדי לגשת למקור, והרשאות עריכה של אובייקטים לכל קטגוריה של Cloud Storage.

כדי להשיג שיפורים בסיסיים באבטחה, העברות אונליין ל-Google Cloud באמצעות הפקודה gcloud storage מתבצעות באמצעות HTTPS, הנתונים מוצפנים במעבר וכל הנתונים ב-Cloud Storage מוצפנים כברירת מחדל במנוחה. אם אתם משתמשים ב-Transfer Appliance, מפתחות אבטחה בשליטתכם יכולים להגן על הנתונים שלכם. באופן כללי, מומלץ לערב את צוות האבטחה כדי לוודא שתוכנית ההעברה עומדת בדרישות של החברה ובדרישות הרגולטוריות.

מוצרים להעברת נתונים של צד שלישי

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

שלב 4: הערכת גישות להעברת נתונים

כשמעבירים נתונים, אפשר לפעול לפי השלבים הכלליים הבאים:

  1. מעבירים את הנתונים מהאתר הקודם לגרסה החדשה של Google Sites.
  2. לפתור בעיות שקשורות לשילוב נתונים, למשל סנכרון של אותם נתונים מכמה מקורות.
  3. מאמתים את העברת הנתונים.
  4. להגדיר את האתר החדש כעותק הראשי.
  5. כשהאתר הקודם כבר לא נחוץ כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

  • כמה נתונים צריך להעביר?
  • באיזו תדירות הנתונים האלה משתנים?
  • האם אתם יכולים להרשות לעצמכם את זמן ההשבתה שנובע מחלון המעבר בזמן העברת הנתונים?
  • מהו מודל עקביות הנתונים הנוכחי שלכם?

אין גישה אחת שהיא הכי טובה, והבחירה תלויה בסביבה ובדרישות שלכם.

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

  • פעולת תחזוקה שנקבעה מראש
  • רפליקציה רציפה
  • כן (כתיבה וקריאה)
  • מיקרו-שירות (microservice) לגישה לנתונים

כל גישה מתמודדת עם בעיות שונות, בהתאם להיקף ולדרישות של העברת הנתונים.

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

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

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

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

פעולת תחזוקה שנקבעה מראש

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

בגישה הזו, ההעברה כוללת את השלבים הבאים:

  1. מעתיקים את הנתונים מהאתר הקודם לגרסה החדשה של Google Sites. העותק הראשוני הזה מצמצם את חלון המעבר. אחרי העותק הראשוני, צריך להעתיק רק את הנתונים שהשתנו במהלך החלון הזה.
  2. מבצעים אימות נתונים ובדיקות עקביות כדי להשוות בין הנתונים באתר המדור קודם לבין הנתונים שהועתקו לגרסה החדשה של Google Sites.
  3. עוצרים את עומסי העבודה והשירותים שיש להם גישת כתיבה לנתונים שהועתקו, כדי שלא יתרחשו שינויים נוספים.
  4. לסנכרן את השינויים שבוצעו אחרי ההעתקה הראשונית.
  5. משנים את עומסי העבודה והשירותים כדי להשתמש באתר החדש.
  6. מפעילים את עומסי העבודה והשירותים.
  7. כשהאתר הקודם כבר לא נחוץ כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

רפליקציה רציפה

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

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

  1. מעתיקים את הנתונים מהאתר הקודם לגרסה החדשה של Google Sites. העותק הראשוני הזה מצמצם את חלון המעבר. אחרי העותק הראשוני, צריך להעתיק רק את הנתונים שהשתנו במהלך החלון הזה.
  2. מבצעים אימות נתונים ובדיקות עקביות כדי להשוות בין הנתונים באתר המדור קודם לבין הנתונים שהועתקו לגרסה החדשה של Google Sites.
  3. מגדירים מנגנון רפליקציה רציף מהאתר הקודם לגרסה החדשה של Google Sites.
  4. עוצרים את עומסי העבודה והשירותים שיש להם גישה לנתונים שרוצים להעביר (כלומר, לנתונים שמעורבים בשלב הקודם).
  5. משנים את עומסי העבודה והשירותים כדי להשתמש באתר החדש.
  6. מחכים עד שהרפליקציה תסנכרן באופן מלא את האתר החדש ב-Google Sites עם האתר הקודם.
  7. מפעילים את עומסי העבודה והשירותים.
  8. כשהאתר הקודם כבר לא נחוץ כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

כן (כתיבה וקריאה)

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

הגישה הזו מסוכמת כך:

  1. משנים את הקוד של עומסי העבודה והשירותים כדי לכתוב נתונים גם באתר הקודם וגם באתר החדש, ולקרוא מהאתר הקודם.
  2. מזהים את הנתונים שנכתבו לפני שהפעלתם את פעולות הכתיבה באתר חדש ב-Google Sites, ומעתיקים אותם מהאתר הקודם לאתר חדש ב-Google Sites. יחד עם ארגון הקוד מחדש הקודם, זה מבטיח שמאגרי הנתונים יהיו מסונכרנים.
  3. מבצעים אימות נתונים ובדיקות עקביות שמשוות בין הנתונים באתר המדור קודם לבין הנתונים בגרסה החדשה של Google Sites.
  4. מעבירים את פעולות הקריאה מהאתר הקודם לגרסה החדשה של Google Sites.
  5. מבצעים עוד סבב של אימות נתונים ובדיקות עקביות כדי להשוות בין הנתונים באתר הקודם לבין הנתונים בגרסה החדשה של Google Sites.
  6. השביתו את הכתיבה באתר מהגרסה הקודמת.
  7. כשהאתר הקודם כבר לא נחוץ כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

מיקרו-שירות (microservice) לגישה לנתונים

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

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

  1. לארגן את הקוד מחדש של מיקרו-שירות הגישה לנתונים כדי לכתוב נתונים גם באתר המדור קודם וגם בגרסה החדשה של Google Sites. פעולות הקריאה מתבצעות באתר הקודם.
  2. מזהים את הנתונים שנכתבו לפני שהפעלתם את פעולות הכתיבה באתר חדש ב-Google Sites, ומעתיקים אותם מהאתר הקודם לאתר חדש ב-Google Sites. יחד עם ארגון הקוד מחדש הקודם, זה מבטיח שמאגרי הנתונים יהיו מסונכרנים.
  3. מבצעים אימות נתונים ובדיקות עקביות כדי להשוות בין הנתונים באתר הקודם לבין הנתונים בגרסה החדשה של Google Sites.
  4. משכתבים את הקוד של מיקרו-שירות הגישה לנתונים כדי לקרוא מהאתר החדש.
  5. מבצעים סבב נוסף של אימות נתונים ובדיקות עקביות, ומשווים בין הנתונים באתר הקודם לבין הנתונים בגרסה החדשה של Google Sites.
  6. לארגן את הקוד מחדש של מיקרו-שירות הגישה לנתונים כך שיכתוב רק באתר חדש ב-Google Sites.
  7. כשהאתר הקודם כבר לא נחוץ כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

שלב 5: הכנה להעברה

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

  1. הערכת מחירים והחזר ROI. בשלב הזה יש הרבה אפשרויות שעוזרות לקבל החלטות.

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

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

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

  3. בדיקת ביצועים. בשלב הזה, מריצים העברה של דגימה גדולה של הנתונים (בדרך כלל 3-5%) אחרי שמשאבי הייצור מוקצים כדי:

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

שלב 6: מוודאים שההעברה תקינה

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

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

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

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

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

שותפים ביצירת התוכן

מחברים: