מעבר אל 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, או במוצר לניהול תהליכי עבודה כמו 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 היא בחינם. עם זאת, אם אתם מארחים את הנתונים שלכם אצל ספק ענן ציבורי, צפוי שתצטרכו לשלם חיוב על תעבורת נתונים יוצאת (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. יש לו גם ממשק משתמש גרפי מנוהל, כך שגם משתמשים לא טכניים (אחרי ההגדרה) יכולים להשתמש בו כדי להעביר נתונים.

שירות העברת הנתונים ל-Cloud Storage עבור נתונים מקומיים שימושי במיוחד בתרחישים הבאים:

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

כדי להגדיר את 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 להעברות ארוכות טווח. שירות העברת נתונים מאפשר ל-Monitoring לעקוב אחרי תקינות הסוכן וקצב העברת הנתונים, כך שתוכלו להגדיר התראות שישלחו לכם הודעה אם הסוכנים לא פעילים או אם הם זקוקים לתשומת לב. חשוב לפעול במקרים של כשלים בסוכנים בהעברות שנמשכות כמה ימים או שבועות, כדי להימנע מהאטה משמעותית או מהפרעות שעלולות לעכב את ציר הזמן של הפרויקט.

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

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

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

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

אם בוחרים באפשרות הזו, חשוב לשים לב לנקודות הבאות:

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

שני הקריטריונים העיקריים שצריך לקחת בחשבון כשמשתמשים ב-Transfer Appliance הם עלות ומהירות. עם קישוריות סבירה לרשת (לדוגמה, 1Gbps), העברת 100TB של נתונים באינטרנט אורכת יותר מ-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 הוא דרך מצוינת להעביר נתונים ולשמור אותם, במיוחד כשמעבירים מ-Cloud ציבורי אחר.

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

אבטחה

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

Product נתונים במצב מנוחה נתונים במעבר גישה למוצר להעברה
‫Transfer Appliance כל הנתונים מוצפנים במנוחה. הנתונים מוגנים באמצעות מפתחות שמנוהלים על ידי הלקוח. כל אחד יכול להזמין מכשיר, אבל כדי להשתמש בו הוא צריך גישה למקור הנתונים.
פקודה אחת (gcloud storage) נדרשים מפתחות גישה כדי לגשת ל-Cloud Storage, שמוצפן במצב מנוחה. הנתונים נשלחים באמצעות HTTPS ומוצפנים בזמן ההעברה. כל אחד יכול להוריד ולהריץ את Google Cloud CLI. כדי להעביר נתונים, צריכות להיות להם הרשאות ל-buckets ולקבצים מקומיים.
‫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. כשכבר לא צריך את האתר הקודם כאפשרות חלופית, צריך להוציא אותו משימוש.

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

שכפול רציף

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחברים: