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

Last reviewed 2024-11-13 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. מזהים את מערכי הנתונים שרוצים להעביר.
    • בוחרים כלים כמו Data Catalog כדי לארגן את הנתונים בקבוצות לוגיות שמועברות ומשמשות יחד.
    • כדאי לעבוד עם צוותים בארגון כדי לאמת או לעדכן את הקבוצות האלה.
  2. מזהים אילו מערכי נתונים אפשר להעביר.
    • כדאי לבדוק אם יש גורמים רגולטוריים, גורמי אבטחה או גורמים אחרים שאוסרים על העברה של מערכי נתונים מסוימים.
    • אם אתם צריכים לבצע טרנספורמציה בחלק מהנתונים לפני שמעבירים אותם (לדוגמה, כדי להסיר מידע אישי רגיש או לארגן מחדש את הנתונים), כדאי להשתמש במוצר לשילוב נתונים כמו Dataflow או Cloud Data Fusion, או במוצר לתזמור תהליכי עבודה כמו Cloud Composer.
  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 היא בחינם. עם זאת, אם אתם מאחסנים את הנתונים שלכם אצל ספק שירותי ענן ציבורי, צפוי שתצטרכו לשלם עמלת תעבורת נתונים יוצאת (egress) ואולי גם עלויות אחסון (למשל, פעולות קריאה) על העברת הנתונים. החיוב הזה חל על נתונים שמגיעים מ-Google או מספק שירותי ענן אחר.
    • אם הנתונים שלכם מאוחסנים במרכז נתונים פרטי שמופעל על ידכם, יכול להיות שיהיו לכם עלויות נוספות על הגדרת רוחב פס נוסף ל Google Cloud.
  • עלויות האחסון והפעולות ב-Cloud Storage במהלך העברת הנתונים ואחריה
  • עלויות מוצרים (לדוגמה, Transfer Appliance)
  • עלויות כוח אדם להרכבת הצוות ולקבלת תמיכה לוגיסטית

זמן ההעברה

יש כמה דברים במחשוב שממחישים את מגבלות החומרה של רשתות, כמו העברה של כמויות גדולות של נתונים. באופן אידיאלי, אפשר להעביר 1 GB בשמונה שניות ברשת של 1 Gbps. אם מגדילים את זה למערך נתונים עצום (לדוגמה, 100 TB), זמן ההעברה הוא 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), העברה של 100 TB של נתונים באינטרנט אורכת יותר מ-10 ימים. אם השיעור הזה מקובל עליכם, סביר להניח שהעברה אונליין היא פתרון טוב לצרכים שלכם. אם יש לכם חיבור של 100 Mbps (או פחות ממיקום מרוחק), אותה העברה תימשך יותר מ-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 של תוכן הקובץ. לפעמים אפשר למצוא את גודל הקובץ והגיבוב באתר המקור. אם לא, תצטרכו גישה מקומית לקבצים, ובמקרה כזה, יכול להיות שיהיה לכם קל יותר להשתמש בפקודה 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. מעבירים נתונים מהאתר הישן לאתר החדש.
  2. לפתור בעיות בשילוב נתונים שמתעוררות – למשל, סנכרון של אותם נתונים מכמה מקורות.
  3. אימות העברת הנתונים.
  4. להעלות את האתר החדש בדרגה כדי שיהיה העותק הראשי.
  5. כשכבר לא צריך את האתר הקודם כאפשרות חלופית, אפשר להוציא אותו משימוש.

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

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

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

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

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

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

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

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

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

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

תחזוקה מתוזמנת

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

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

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

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

שכפול רציף

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

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

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

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

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

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

הגישה הזו מסוכמת באופן הבא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחברים: